INTERNET-DRAFT R. Bouziane Intended status: Standards Track SecRoot.io September 16, 2025 Expires: March 16, 2026 OODA-HTTP: Adaptive Security Framework for HTTP Communications draft-secroot-ooda-http-02 Abstract This document defines OODA-HTTP, a protocol extension and adaptive security framework that applies the Observe-Orient-Decide-Act (OODA) loop to HTTP/HTTPS communications. Each HTTP request is transformed into an observation signal, a decision vector, and an opportunity for active defense. OODA-HTTP extends the traditional 4-phase loop into 7 phases: Observe, Orient, Decide, Act, Memorize, Adjust, and Cooperate - allowing systems to evolve and adapt during communication. The protocol introduces a structured header, 'OODA-Action', that carries context-driven actions between endpoints. OODA-HTTP offers compatibility with existing infrastructure (e.g., TLS, HTTP/2/3), while enabling resilience against classical, behavioral, and quantum threats. It supports inter-protocol cooperation with DOTS, STAMP, SIEMs, and behavioral inference engines such as SVDD and PSLPSO. This document defines protocol behavior, header format, core logic, and interoperability strategy. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html This Internet-Draft will expire on January 18, 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Terminology 3. Architectural Overview 4. OODA-HTTP Phases 5. Message Formats and Protocol 6. Threat Models and Detection 7. Applications and Case Studies 8. Integration with TLS/HTTPS 9. Protocol Engineering Foundations 10. Security and Privacy Considerations 11. IANA Considerations 12. Vector Engine and Temporal Memory 13. Interoperability with External Agents (DOTS, STAMP, SVDD, PSLPSO) 14. Strategic Doctrine 15. Layered Threat Classification (OSI vs OODA) 16. Frontend Sensors and OODA-DOM 17. OODA-DOM Good Practices Map 18. State Memory and Client-Side Persistence 19. Server-Side and Component-Based Integration 20. OODA Engine Requirements and Incremental Models Appendix A. Developer Guidance Appendix B. Unified OODA Action Registry 1. Introduction HTTP and HTTPS communications are increasingly targeted by sophisticated threats, including intelligent automation, behavioral evasion, and quantum-capable attacks. Traditional HTTPS, while providing encryption, relies on static pre-negotiated parameters and lacks mechanisms for real-time behavioral defense. OODA-HTTP introduces an adaptive security layer built upon the OODA loop: Observe, Orient, Decide, and Act. Inspired by decision models in dynamic environments, this extension enables endpoints, proxies, and applications to assess context and respond defensively in real time. Beyond the original loop, OODA-HTTP incorporates three additional phases: Memorize, Adjust, and Cooperate. These phases allow systems to learn from observed behavior, adapt their detection strategies, and collaborate with external agents such as DOTS controllers, SIEM platforms, and TLS telemetry analyzers. Each HTTP request becomes more than a data exchange - it is treated as a semantic signal, a decision vector, and a potential reflex trigger. OODA-HTTP transforms passive transport into an intelligent, self- defending protocol layer. This document defines the architecture, phases, message formats, use cases, and integration models required to deploy OODA-HTTP in modern HTTP/HTTPS infrastructures. 2. Terminology OODA Loop: A four-phase decision model: Observe, Orient, Decide, Act. Originally from military strategy, now applied to cybersecurity and protocol logic. OODA-HTTP: An extension of HTTP that enables contextual decision-making through adaptive security headers, behavioral memory, and coordination with external agents. The OODA-HTTP engine implements a seven-phase loop. OODA-Action: A structured HTTP header used to transmit threat context, scores, and defensive actions. Replaces the deprecated X-prefixed variant. Threat Score: A numeric risk indicator (0-100) assigned to a session or request based on contextual analysis. Temporal Memory: A mechanism to track behaviors, entropy, and anomalies across multiple requests over time. Semantic Vector: A structured representation of a session's metadata, timing, and behavioral fingerprint. Used to detect behavioral drift or identity replays. SVDD: Support Vector Data Description - A model to learn the boundary of normal behavior and detect anomalies. PSLPSO: Polynomial Self-Learning Particle Swarm Optimization - A metaheuristic algorithm to optimize model hyperparameters. STAMP: System-Theoretic Accident Model and Processes - A framework to understand root causes of systemic or behavioral failures. Cooperative Defense: Cross-agent sharing of security context, trust levels, and adaptive intentions. Fiche: A lightweight execution module in the OODA-HTTP engine. Each fiche implements one function in the OODA loop (e.g., scoring, memory, orientation). Fiches can be composed, replaced, or versioned independently. Behavioral Identity Trace: A persistent, cumulative profile of a client's session behavior across time. Used by Memorize and Adjust phases to detect evasive patterns or delayed attacks. OODA Registry: A JSON-based registry of available actions, scores, categories, and policy mappings used by Decide and Act phases. Vector Engine: A core component of the Orient phase responsible for constructing, comparing, and storing semantic vectors associate 3. Architectural Overview OODA-HTTP introduces an adaptive security layer within HTTP/HTTPS communication flows. It transforms each HTTP request into a semantic event processed through a modular decision loop based on the OODA model. At its core, the architecture extends the traditional 4-phase OODA loop (Observe, Orient, Decide, Act) into a 7-phase reflex loop: Observe -> Orient -> Decide -> Act -> Memorize -> Adjust -> Cooperate This extension equips HTTP servers and proxies with real-time self- defensive capabilities, transforming them into intelligent agents capable of detecting, responding to, and learning from behavioral threats. The OODA-HTTP engine is organized into modular functional blocks, each aligned with a phase of the loop. These modules can be deployed individually or as a complete pipeline, depending on operational needs. +-----------+ +-----------+ +-----------+ +--------+ | Observe |-> | Orient |-> | Decide |-> | Act | +-----------+ +-----------+ +-----------+ +--------+ ↓ ↓ ↓ ↓ (DOM, TLS) (Vectors, Scores) (Policy) (Actions) ↓ ↓ ↓ ↓ +------------+ +-----------+ +------------------------+ | Memorize | | Adjust | | Cooperate | +------------+ +-----------+ +------------------------+ ↓ ↓ ↓ (Trace) (Tuning) (DOTS, STAMP, SIEM) Key architectural components include: - **Observe:** Captures incoming request signals such as HTTP headers, user-agent strings, TLS handshake metadata, request frequency, and temporal patterns. At the frontend, DOM instrumentation (OODA-DOM) can contribute additional behavioral data (e.g., typing patterns, interaction anomalies, tab focus). - **Orient:** Processes observed signals to construct a contextual trace. This includes semantic enrichment, memory correlation, and optional embedding into vector space. Orientation is supported by scoring models such as SVDD, with dynamic tuning via PSLPSO. - **Decide:** Applies decision logic based on thresholds, risk profiles, and detection rules. Decisions may include classifying the request as trusted, suspicious, automated, abusive, or unknown. - **Act:** Executes the selected action in real time. Possible actions include forwarding, delaying, rejecting, annotating (e.g., tagging with a `OODA-Action` header), or applying countermeasures such as key rotation, CAPTCHA enforcement, or entropy tests. - **Memorize:** Stores persistent behavioral identities, vector traces, and session-based scores. This phase enables the engine to evolve contextually by maintaining memory of request trajectories across time. - **Adjust:** Continuously refines detection models and thresholds based on observed behavior, feedback loops, and temporal patterns. This enables adaptive scoring and risk management tailored to environments. - **Cooperate:** Interfaces with external protocols and infrastructure such as DOTS (RFC 9132), STAMP, TLS proxies, and SIEM platforms. This allows sharing of insights, coordination of defense posture, and propagation of awareness across distributed systems. Each functional block is implemented as a discrete module (called a "fiche") that can be audited, configured, and composed to fit deployment-specific requirements. OODA-HTTP is designed to be: - **Modular:** Each phase can operate independently or as part of a unified engine. - **Lightweight:** Minimal performance overhead by embedding logic at request time. - **Composable:** Deployable on the edge, server-side, or client-side. - **Backwards-compatible:** Fully compatible with HTTP/1.1, HTTP/2, and interoperable with HTTP/3 and QUIC. This architecture enables OODA-HTTP to act as a reflexive overlay that enhances HTTP/HTTPS with native self-defense mechanisms, without centralized orchestration or cloud-based inspection. The transition from the classic OODA model to the 7-phase OODA-HTTP loop is not purely theoretical: it is operationalized via concrete, testable modules and designed for real-time execution. The following section (Section 4) details the extended loop and its role in HTTP-native decision-making. 4. The OODA Loop and Its Extension in HTTP The OODA loop (Observe, Orient, Decide, Act) was originally developed as a decision-making framework in military contexts to describe how agents can respond dynamically to evolving situations. In the context of network communications, this loop provides a compelling foundation for adaptive defense mechanisms. OODA-HTTP implements and extends this model directly within the HTTP processing stack, transforming each HTTP request into both a signal and a decision point. This allows servers to evaluate client behavior in real time, reason over context, and take action without depending on external rule sets or cloud-based analysis layers. The classical four phases of the OODA loop are: - Observe: Gather input from the environment (request headers, payloads, timing, client context). - Orient: Analyze and interpret the input in light of past behavior, session history, and semantic meaning. - Decide: Select the most appropriate action or classification based on current context, scores, and thresholds. - Act: Execute the decision (e.g., forward, delay, redirect, reject, log, annotate). OODA-HTTP extends the loop with three additional phases to enable persistence, learning, and collaboration: - Memorize: Persist historical behaviors, request traces, and scores into a temporal memory structure. - Adjust: Update scoring models, detection thresholds, or feature weightings in light of evolving behavior patterns or newly observed anomalies. - Cooperate: Exchange contextual insights or warning signals with external agents such as DOTS clients, XDR platforms, or security orchestration systems. This extended model yields a 7-phase reflex loop: Observe -> Orient -> Decide -> Act -> Memorize -> Adjust -> Cooperate It reflects a living system - one that learns, adapts, and collaborates across the lifecycle of HTTP communications. In this paradigm, each HTTP request becomes not only a transport unit, but also a semantic event, contributing to a persistent, evolving understanding of network behavior. Unlike abstract models, OODA-HTTP is built on an operational engine, composed of discrete and modular components. Each phase is powered by dedicated functional units, documented through a structured series of engineering fiches. For example: - The Observe phase is implemented through modules that capture request signals, client behavior patterns, and session dynamics. - The Orient phase is supported by trace analyzers, vectorization routines, and contextual enrichers. - The Decide and Act phases are handled by embedded rule engines and response controllers. - Memory and Adaptation are governed by evolving state management structures and score feedback loops. - Cooperation is enabled via connectors to external telemetry systems and threat intelligence relays. Each of these components is designed as a fiche - a standardized, auditable, and modular building block. Together, they allow the OODA- HTTP engine to operate incrementally and autonomously across request flows. OODA-HTTP does not merely defend. It evolves - through embedded logic, adaptive behavior, and cooperative defense. As OODA-HTTP redefines the HTTP processing model through an extended loop of adaptive decision-making, it is essential to clarify how this approach aligns with and complements existing Internet protocols. The following section outlines the positioning of OODA-HTTP in relation to established standards such as TLS, DOTS, and STAMP, highlighting how OODA-HTTP does not replace but extends their capabilities with real- time, request-level reflexes. 4.1 Observe Phase The Observe phase is the initial entry point of the OODA-HTTP loop. It is responsible for capturing all available signals from the incoming HTTP request and its environment. Observation in OODA-HTTP goes beyond traditional packet inspection or header parsing. It includes: - Request metadata (method, path, headers, size, timing) - Session continuity (cookies, tokens, behavioral flow) - Temporal patterns (burst frequency, idle gaps, retries) - Frontend signal injection (via OODA-DOM where applicable) These observations are collected in a structured behavioral trace, forming the basis for subsequent semantic analysis. This phase is powered by a series of sensor components (documented as engineering fiches) that specialize in signal capture, logging, rate tracking, and correlation across requests and sessions. The output of this phase is a normalized context trace, which is forwarded to the Orientation phase. 4.2 Orient Phase The Orient phase processes the observed data and transforms it into meaningful behavioral context. This step involves contextualization, enrichment, and preparation of features for decision-making. It includes: - Mapping request patterns to known behavioral classes - Correlating current data with past traces (temporal context) - Building semantic vectors representing client behavior - Scoring interactions based on configurable heuristics Orientation acts as the analytical core of the loop, transforming raw input into actionable knowledge. In doing so, it draws from both local memory (recent requests) and persistent memory (long-term scores). Multiple engine components contribute to this phase: vector analyzers, scoring modules, memory readers, and enrichment agents - each defined as an auditable fiche within the OODA-HTTP framework. The resulting oriented context is then passed to the Decide phase for evaluation. 4.3 Decide and Act Phases The Decide phase evaluates the oriented behavioral context produced in the previous step. It is responsible for selecting an appropriate course of action based on scoring thresholds, classification models, and response policies. Decision-making can be based on: - Request-level scores (e.g., behavioral anomaly, session risk) - Rule matches (e.g., pattern detection, blacklists, policy triggers) - Historical trace evaluation (e.g., rate escalation, score increase) The Act phase then enforces the selected action in response to the HTTP request. Examples include: - Forwarding the request as-is - Modifying headers (e.g., adding `X-OODA-Action` or marking risk levels) - Delaying or throttling the response - Dropping or rejecting the request with context-aware messages - Logging, alerting, or triggering external events These two phases operate in tight succession and are implemented by action-oriented fiches such as scoring dispatchers, route switchers, or adaptive throttling modules. Crucially, the decision logic is both local and dynamic. No central server or external orchestration is required, enabling real-time responsiveness within the HTTP processing path. 4.4 Positioning of OODA-HTTP in Relation to Existing Protocols OODA-HTTP introduces a reflex loop directly into the HTTP stack, augmenting each request with local intelligence and adaptive behavior. While its capabilities are unique, its role is complementary to existing protocols rather than competitive or substitutive. - Compared to TLS: TLS ensures encryption and integrity. OODA-HTTP operates above TLS, focusing on behavioral analysis and decision- making after decryption - without modifying the TLS layer itself. - Compared to DOTS (DDoS Open Threat Signaling): DOTS provides centralized volumetric attack signaling. OODA-HTTP adds per-request defense logic, enabling instant response to stealthy or application- layer threats. - Compared to STAMP and performance monitoring protocols: STAMP provides metrics for observability. OODA-HTTP integrates such metrics into a decision-making framework for threat mitigation. By embedding real-time reflexes within the HTTP communication path, OODA-HTTP extends the Internet protocol toolbox with a semantic, session-aware, and autonomous layer of defense. As such, it is best understood not as a replacement, but as a complement - enabling a new class of protocols where the server becomes an active, decision-capable agent in its own security posture. 5. Message Format and Protocol OODA-HTTP introduces a structured HTTP header named 'OODA-Action'. This header conveys threat scores, classification categories, and recommended mitigation actions between client, server, edge proxy, or security middleboxes. The header enables runtime decisions to be communicated across the HTTP lifecycle, and supports both passive evaluation and active intervention based on local or distributed policies. Example: OODA-Action: { "score": 82, "category": "suspicious", "action": "challenge", "timestamp": "2025-07-06T20:32:10Z" } Fields: score (integer): A numeric value between 0 and 100 indicating the perceived threat level associated with the request or session. Scores above configurable thresholds may trigger defensive actions. category (string): A human-readable classification of the context. Typical values include 'normal', 'suspicious', or 'malicious'. action (string): A recommended security response. Supported values include: * allow - Permit the request normally. * block - Reject the request immediately. * throttle - Introduce latency or rate limits. * challenge - Request additional proof (e.g., CAPTCHA, MFA). timestamp (string): ISO 8601 formatted UTC time of decision generation. Used for synchronization, log correlation, and caching logic. This header may be generated by the server, an edge gateway, a CDN node, or even the browser (in OODA-DOM deployments). It can also be inserted or modified by intermediary security appliances as long as trust models permit. Implementations SHOULD favor structured JSON for extensibility and clarity. In constrained environments, compact binary or base64-encoded variants MAY be used, provided semantic equivalence and cross-version compatibility. Additionally, OODA-Action headers can be layered: - A client may send an initial OODA-Action (e.g., from DOM fingerprinting). - A proxy may append policy-based decisions (e.g., via reverse proxy logic). - A server may compute a final OODA-Action based on telemetry fusion, behavioral memory, or external coordination (e.g., DOTS, STAMP). All OODA-Action headers MUST preserve traceability by including metadata about the originating component, when multiple evaluations are performed. This is essential to support cooperative defense and auditability. Example with layered context: OODA-Action: { "score": 92, "category": "malicious", "action": "block", "origin": "edge-proxy-eu3", "timestamp": "2025-07-06T20:32:10Z", "confidence": "high" } Future extensions MAY define additional fields such as: - confidence levels - sub-scores per model - mitigation intents - trust assertions or cryptographic proofs The structure of the header and its registry of values are detailed in Appendix B (Unified OODA Action Registry). 6. Threat Models and Detection OODA-HTTP is designed to address multiple categories of threats across both application-level behaviors and lower-layer protocol interactions. Its 7-phase architecture enables continuous observation, evaluation, and response during HTTP communication. 6.1. Classical Threats These include protocol-level and infrastructure attacks commonly addressed by traditional firewalls and rate-limiters, but now integrated into adaptive HTTP logic: - DoS / DDoS floods (volumetric or protocol-based) - Slowloris and low- rate TCP connection exhaustion - Header manipulation (e.g., spoofed User-Agent, forged cookies) - Session replay and token/cookie theft OODA-HTTP provides real-time scoring and behavioral fingerprinting, allowing precise throttling or blocking even under polymorphic attacks. 6.2. Behavioral Threats Modern threats increasingly mimic legitimate users. OODA-HTTP detects deviations through session memory and pattern analysis: - Irregular navigation paths or rage clicks - Bots rotating User-Agent and avoiding Referer headers - High-frequency scraping or burst access patterns - Timing anomalies or inconsistent cookie behavior The engine uses vector signatures and temporal memory to differentiate real users from automated threats - even when content and headers appear valid. 6.3. Quantum-Related Threats While quantum computers are not yet mainstream, future-proofing is critical. OODA-HTTP monitors entropy and handshake quality to detect or deter: - Low-entropy handshakes vulnerable to Grover-based attacks - Poor randomization in TLS session key generation - Delayed decryption scenarios leveraging Shor's algorithm Adaptive defenses include entropy reinforcement, dynamic TLS re- negotiation, and integration with post-quantum-ready entropy sources. 6.4. Cross-Layer Interoperability To strengthen situational awareness, OODA-HTTP integrates with external defense systems such as DOTS (DDoS Open Threat Signaling) and STAMP (System-Theoretic Accident Model and Processes). This integration allows: - Exchange of early-warning signals and mitigation requests (via DOTS push) - Coordination with TLS/QUIC layers for handshake inspection - Feedback loops between application scoring and network-layer telemetry For example, a DOTS signal indicating volumetric stress can influence OODA-HTTP's decision to throttle or challenge even benign requests under pressure. 6.5. Layer Mapping OODA-HTTP spans multiple OSI layers: - Layer 3-4: Collaborates with DOTS, TLS/QUIC, and firewall metadata - Layer 7: Analyzes HTTP headers, cookies, timing, DOM events - Cross- layer: Reacts to feedback from SIEM, ML detectors, or edge proxies This multi-layered detection strategy ensures coordinated responses without fragmenting the defense logic. It also allows fine-grained decision-making at each layer while maintaining a unified threat context. 7. Applications and Case Studies OODA-HTTP has been tested across a variety of deployments - edge, proxy, gateway, and browser - to illustrate how its 7-phase loop adapts in practice. Each case demonstrates how HTTP requests become decision vectors for defense. 7.1. CDN Burst Detection A CDN deployed OODA-HTTP at the edge layer to mitigate flash crowd events and bot-driven bursts. Using the Observe and Decide phases, traffic flow was scored in real time. Sample outcome: OODA-Action: { "score": 74, "category": "burst", "action": "throttle" } This action was propagated back to the client via the edge, applying rate controls without breaking session continuity. 7.2. Reverse Proxy Slowloris Defense In a reverse proxy setup, the Memorize phase tracked slow socket behaviors and incomplete headers. Orient detected timing anomalies, and Decide triggered a block action for connection exhaustion attempts. Sample outcome: OODA-Action: { "score": 91, "category": "low-rate", "action": "block" } 7.3. Bot Detection at the Application Gateway A web application integrated a semantic vector engine using SVDD + PSLPSO. Behavioral inconsistencies across navigation paths were detected. OODA-HTTP inferred bot camouflage (rotating User-Agent + no Referer) and challenged the user. Sample outcome: OODA-Action: { "score": 88, "category": "bot- camouflage", "action": "challenge" } 7.4. Quantum Resilience Testbed In a TLS 1.3 testbed, OODA-HTTP monitored entropy quality during session negotiation. When entropy from the client nonce appeared predictable,OODA-HTTP suggested secret rotation through internal memory flags. This scenario demonstrates the engine's Adjust phase in action - without modifying TLS itself. 7.5. Frontend Adaptation via OODA-DOM DOM-aware applications used OODA-DOM (Section 16) to issue headers from the browser based on local behavioral cues. Example behaviors: - Triggering CAPTCHA dynamically: action = "challenge" - Disabling advanced UI features on high-risk sessions - Logging or sampling suspicious clickstreams for Memorize This proves that the frontend becomes a sensor and active participant in defense, not just a passive receiver. Each of these case studies reflects the strength of the extended OODA loop: Observe -> Orient -> Decide -> Act -> Memorize -> Adjust -> Cooperate The next section details how OODA-HTTP wraps TLS/HTTPS to integrate seamlessly with transport-layer encryption. 8. Integration with TLS/HTTPS OODA-HTTP is explicitly designed to operate in conjunction with existing TLS and HTTPS infrastructures. It does not modify the TLS wire format, cryptographic handshake, or encryption semantics. Instead, it introduces a behavioral and contextual overlay at the HTTP application layer, which can interact with TLS indirectly through telemetry, session metadata, and coordinated control paths. This section outlines how OODA-HTTP enhances TLS-aware systems without violating protocol separation or interoperability: 8.1. TLS Interaction Model OODA-HTTP does not alter TLS wire formats or cryptographic protocols. Instead, it passively observes metadata exposed at the TLS termination point, such as cipher negotiation, handshake entropy, and session reuse. 8.1.0. HTTP/1.1 and HTTP/2 Interaction OODA-HTTP is fully compatible with HTTP/1.1 and HTTP/2. It uses standard headers to carry adaptive security context across existing connections, without modifying framing or wire-level semantics. +-----------------+ HTTP/1.1 or 2 +------------------+ | CL (Client/DOM) | <=== Req/Resp + Headers ===> | SRV (Server/RP) | +-----------------+ +------------------+ | | | Transparent Header Injection / Inspection | v v +-----------------+ +------------------+ | TCP (Client) | <=========================> | TCP (Server) | +-----------------+ +------------------+ Legend: CL = Client (browser, agent) SRV = Server or reverse proxy HTTP/1.1: Text-based protocol over TCP HTTP/2: Binary multiplexed protocol over TCP Key properties: - OODA-HTTP headers (`OODA-Action`) are valid in both versions - No changes to HTTP framing or connection behavior - Compatible with intermediate proxies, CDNs, and inspection tools 8.1.1. QUIC/HTTP3 Interaction OODA-HTTP supports QUIC by observing handshake metadata exposed at endpoints or through QUIC-aware proxies, without altering wire behavior. +-----------------+ HTTP/3 Layer +------------------+ | CL (Client/DOM) | <=== Req/Resp + Headers ===> | SRV (Server/RP) | +-----------------+ +------------------+ | | | QUIC Telemetry Observation (meta) | v v +-----------------+ +--------------------+ +-----------------+ | QUIC (Client) | <-> | QP (QUIC Proxy) | <-> | QUIC (Server) | +-----------------+ +--------------------+ +-----------------+ Legend: CL = Client or browser (DOM-capable) SRV = Server or reverse proxy QP = QUIC proxy or observability point QUIC = HTTP/3 transport layer over UDP Key properties: - OODA-HTTP does not modify QUIC transport or TLS over QUIC - QUIC metadata (timing, flow IDs, handshake entropy) is passively read - Actions remain confined to the HTTP/3 layer via OODA-Action headers 8.2. Entropy Awareness and Anomaly Detection In scenarios where entropy quality is critical - such as in IoT, embedded clients, or weak RNG environments - OODA-HTTP modules can monitor entropy characteristics of session keys or handshake fields. Indicators of concern may include: - Repetitive or low-entropy client random values - Predictable session resumption behavior - Use of outdated cipher suites lacking forward secrecy Upon detection, the engine may raise the session's threat score or flag it for deeper inspection. 8.3. Key Rotation Coordination OODA-HTTP does not initiate TLS key exchange or renegotiation on its own. However, in deployments where TLS keying material is managed by a programmable agent (e.g., TLS termination proxy), OODA-HTTP may suggest re-keying events in response to elevated threat scores. This coordination is out-of-band, typically through: - Management APIs (e.g., QUIC TLS stack integration) - IPC or shared memory hooks in NGINX/Envoy-type proxies - Dynamic reconfiguration scripts 8.4. Contextual Tagging of TLS Sessions In multipath or multiplexed HTTP/2 and HTTP/3 environments, a single TLS connection may carry diverse request profiles. OODA-HTTP allows tagging of each request (via `OODA-Action` header) with behavioral context. This allows: - Session correlation for SIEM or XDR systems - Policy enforcement per HTTP request rather than per connection - Delegation of TLS-level context back to higher-layer decision engines 8.5. Post-Quantum Preparedness While OODA-HTTP does not alter cryptographic primitives, it can be used to simulate post-quantum threat conditions: - Triggering alerts for weak or legacy handshakes - Logging handshake entropy levels for audit or telemetry - Adapting runtime posture (e.g., throttling, challenge, isolate) based on TLS layer confidence This bridges the gap between static TLS negotiation and real-time behavioral adaptation. 8.6. Summary OODA-HTTP does not interfere with the TLS handshake or encryption semantics. Its role is to enrich HTTP behavior **after** the secure channel is established, by: - Observing TLS parameters for contextual scoring - Influencing policy decisions at the HTTP layer - Supporting external coordination with TLS- aware components In doing so, OODA-HTTP transforms passive secure channels into **context-sensitive**, **risk-aware** conduits - while remaining fully compatible with TLS 1.3, QUIC, and existing HTTPS deployments. 9. Protocol Engineering Foundations OODA-HTTP is engineered as an overlay, not a replacement. It operates at the HTTP application layer and leverages standard-compliant header injection to carry decision signals. The design philosophy emphasizes: - Compatibility with all HTTP versions (1.1, 2, 3) - No changes to TCP, QUIC, or TLS wire protocols - Support for both stateless and stateful deployments - Forward extensibility through structured headers OODA-HTTP follows key engineering principles: 9.1 Minimal Invasiveness OODA-HTTP does not modify existing transport layers. It is deployable via proxies, middleware, service meshes, or edge nodes without changes to client libraries or core protocols. 9.2 Deterministic Behavior Actions derived from threat scoring (e.g., block, throttle, rotate-keys) must be deterministic and auditable. Engines must avoid random behaviors that could impact traceability or compliance. 9.3 Header Formalism The `OODA-Action` header must follow a defined schema. Optional fields may be ignored without loss of compatibility. JSON is the preferred encoding but CBOR or compact forms may be adopted in constrained environments. 9.4 Stateless by Default Although Memorize and Adjust phases imply state, default deployments may opt for ephemeral scoring and actions without persistent memory. Stateful modes are available for advanced use cases. 9.5 Upgrade Path OODA-HTTP supports progressive rollout. It can be introduced incrementally in reverse proxies, CDNs, or clients. Clients unaware of `OODA-Action` can still interoperate seamlessly. 9.6 Testing and Validation Each deployment should include replay testing, entropy validation, and attack emulation scenarios. Threat simulation must include slow clients, bot agents, and low-entropy TLS sessions. 9.7 Threat Mapping Across OSI Layers OODA-HTTP operates at the application layer but observes behaviors that span multiple OSI layers. The engine captures anomalies that originate from transport-level, session-level, or even link-level irregularities as observed through HTTP metadata. The following attack mapping shows the relevance of each OSI layer: +------+-------------------------------+-----------------------------+ | Layer| Example Threats | OODA-HTTP Detection Role | +------+-------------------------------+-----------------------------+ | 7 | Bot, click fraud, scraping | Behavior scoring, DOM | | 6 | Malformed headers, encoding | Header sanitization | | 5 | Session replay, TLS reuse | Entropy check, ID trace | | 4 | Slowloris, burst TCP flood | Timing analysis, throttle | | 3 | IP spoofing, routing games | Context fingerprinting | | 2 | MAC spoofing (via proxy) | Trust anchor misalignment | +------+-------------------------------+-----------------------------+ Although not a transport-layer protocol, OODA-HTTP enables context-aware mitigation based on symptoms emerging at lower layers. This aligns with STAMP-based reasoning and reinforces cooperative defense with systems like DOTS, TLS inspection proxies, or edge SIEMs. 10. Security and Privacy Considerations OODA-HTTP introduces active decision elements into HTTP traffic. This requires careful analysis of how scores, actions, and behavioral memory are processed and shared. 10.1 Integrity of OODA-Action Headers Intermediaries must validate the authenticity and integrity of `OODA- Action` headers. Unsigned or tampered headers may mislead agents into inappropriate actions. Future drafts may define a signature scheme. 10.2 Replay and Tampering Risks As OODA-Action may influence access control or TLS rotation, replayed or modified headers can pose security risks. Servers should timestamp and scope each action to a request ID or session context. 10.3 Privacy Implications Behavioral scoring and memory storage introduce privacy exposure. Scores must not leak identifiable traits unless explicitly authorized. Systems should anonymize session traces and comply with privacy regulations. 10.4 False Positives and Negatives Adaptive systems may misclassify benign traffic. It is critical to allow feedback loops, override mechanisms, and audit trails. Tuning must balance detection with usability. 10.5 Scope of Defense OODA-HTTP defends at the HTTP edge. It is not a substitute for transport encryption, network ACLs, or endpoint security. It complements these by introducing application-level adaptivity. 10.6 Trust and Delegation In multi-layer deployments (CDN, reverse proxy), action authority must be clearly defined. Misaligned trust assumptions may cause conflict between layers or over-block legitimate traffic. 11. IANA Considerations This document registers the following HTTP header under the "Permanent Message Header Field Names" registry: Header Field Name: OODA-Action Applicable Protocol: HTTP Status: Provisional Change Controller: IETF Specification Document: This document This header was initially named X-OODA-Action in early drafts. Following community feedback and IETF best practices, the "X-" prefix was removed to reflect intended standardization. Future updates may request ALPN or TLS extension identifiers as inter- protocol coordination evolves. 12. Vector Engine and Temporal Memory OODA-HTTP integrates a semantic vector engine that captures behavioral signals and organizes them into structured vectors, enabling dynamic learning and memory-driven decisions. 12.1 Observation Vectors Each HTTP request generates an observation vector composed of metadata, TLS negotiation traits, entropy metrics, timing signals, and navigation behavior. This vector becomes the atomic input for the semantic engine. 12.2 Orientation and Semantic Space Observation vectors are mapped into a semantic space using anomaly detection models such as SVDD. Hyperparameter tuning is performed in real time via PSLPSO, a self-adaptive optimization technique. This enables the system to learn new patterns incrementally. 12.3 Temporal Memory Two memory layers are maintained: - Short-term memory detects session bursts, replay attacks, or timing anomalies across consecutive requests. - Long-term memory records entropy trends, vector signatures, and evolving identity traits. It enables slow-pattern detection and behavioral drift monitoring. 12.4 Learning by Activity The vector engine evolves with traffic. Each new request contributes to pattern refinement. Memory is not static: like a human pilot, the system builds instinct through repeated exposure. This supports anticipatory security and contextual decision-making. 13. Interoperability with External Agents OODA-HTTP is designed to interoperate with external protocols and engines to enable layered, cognitive defense. It acts as a coordination layer that synthesizes behavior, decisions, and threat intelligence across domains. 13.1 DOTS (DDoS Open Threat Signaling) OODA-HTTP supports coordination with DOTS (RFC 9244) by: - Receiving upstream mitigation signals from a DOTS server and converting them into contextual HTTP responses using OODA-Action headers. - Exporting local threat scores or observations toward DOTS clients or collectors, facilitating upstream analytics or multi-tenant mitigation. 13.2 SVDD (Support Vector Data Description) During the Orient phase, SVDD is used to learn the hyperspace of normal behavior. Each incoming request vector is checked for proximity to this boundary. Anomalous vectors increase the risk score for Decide phase logic. 13.3 PSLPSO (Polynomial Self-Learning Particle Swarm Optimization) PSLPSO tunes the SVDD model's hyperparameters over time. This includes: - Radius tightening/loosening based on feedback. - Adjusting thresholds adaptively as behavior evolves. - Auto-rebalancing class boundaries with no supervision. 13.4 STAMP (System-Theoretic Accident Model and Processes) STAMP provides a causal framework for analyzing behavioral incidents. OODA-HTTP uses STAMP integration to: - Trace anomalous patterns to root causes (bad session chains). - Feed Memorize and Adjust phases with causal awareness. - Support forensic correlation and explainability of decisions. 13.5 Semantic Fusion OODA-HTTP can merge these signals into a semantic decision vector. Example function: orient_merge(dot_signal, svdd_score, stamp_root); The result feeds Decide and Act logic, giving OODA-HTTP a predictive, interoperable edge. This forms the backbone of a layered cyber-defense architecture that evolves through feedback, learning, and cooperation. 13.6 Comparative Advantage: Application-Layer Defense While DOTS (RFC 9244) supports upstream mitigation signals, it lacks application-layer insight. It cannot process user behavior, TLS entropy, or HTTP headers. OODA-HTTP fills this cognitive gap. OODA-HTTP provides real-time, semantic decision-making at the edge or server, complementing DOTS at the transport/network layers. Without OODA-HTTP, DOTS is blind to: - Camouflaged bots or HTTP anomalies. - Low-entropy TLS handshakes. - Inconsistent navigation or session flow. Together, they form a layered defense model: +-------------------------------+ | External Intelligence | | (SIEM, SOC, DOTS) | +---------------+---------------+ | v +-------------------------------+ | OODA-HTTP Core | | - Orient, Memorize, Cooperate | | - Semantic Vectors, Scores | +---------------+---------------+ | +----------+---------+----------+----------+ | | | | v v v v TLS Layer HTTP/2-3 Proxies/CDN DOM Sensors DOTS absorbs volume. OODA-HTTP interprets meaning. They are complementary: pressure relief and adaptive reflex. 14. Strategic Doctrine and Cybersecurity Philosophy OODA-HTTP is not only a protocol; it is a doctrine. It redefines security as a continuous decision cycle that adapts to adversaries in real time. Traditional HTTP security is reactive and passive. OODA-HTTP is proactive, evolutionary, and collaborative. This doctrine is built on two fundamental laws: Law #1 - Adaptive Memory Law: A system that does not remember cannot evolve. OODA-HTTP embeds memory as a first-class protocol construct, ensuring that each observation improves future decisions. Law #2 - Cooperation over Isolation: A defense that does not cooperate is already defeated. OODA-HTTP is designed for interoperation with DOTS, TLS inspectors, STAMP, and future telemetry agents. 14.1. Key Transparency and Behavioral Fingerprinting OODA-HTTP introduces key transparency mechanisms at the behavioral level. Rather than verifying certificates alone, it memorizes and correlates key material (e.g., TLS session fingerprints) across time, ASN, and context. The module `ooda_memorize.c` tracks fingerprint evolution across sessions. The module `ooda_cooperate.c` can export suspicious fingerprints to DOTS or SIEM systems. The `Orient` phase can flag rapid or inconsistent key rotations. The `Act` phase can trigger: OODA-Action: alert-key-anomaly Transparency in OODA-HTTP is not purely cryptographic - it is contextual, temporal, and strategic. It complements existing PKI mechanisms such as Certificate Transparency (CT), OCSP, or CRLs by integrating behavioral indicators into the decision loop. A self-defending protocol must remember the keys it trusts, not just accept them. 15. Layered Threat Classification (OSI vs OODA) Traditional security frameworks classify threats by OSI layer: physical, network, transport, application. OODA-HTTP reclassifies them by cognitive phase. This layered model enables cross-phase correlation and shows how OODA- HTTP complements or augments existing security layers. +----+---------------------------+-----------------+------------------+ |Lvl|Example Threats |OODA Phase |OODA Response | +----+---------------------------+-----------------+------------------+ |L3 |IP spoofing,DDoS |Observe,Memorize |rate-limit,alert | |L4 |Slowloris,SYN flood |Observe,Orient |drop,timeout | |TLS|Entropy replay,downgrade |Orient,Memorize |key-rotate,reject | |L7 |Header anomalies,replay |Observe,Orient |challenge,drop | |APP|Credential stuffing,bots |Decide,Act |captcha,ban,log | |ML |Coordinated APT attack |Cooperate,Adjust |notify-DOTS,score++| +----+---------------------------+-----------------+------------------+ This model reinforces that defense is no longer vertical (per layer), but looped and adaptive, where OODA phases interleave to correlate weak signals and respond intelligently. OODA-HTTP is the first protocol to introduce horizontal correlation across vertical layers, enabling end-to-end cognitive security pipelines. 16. Frontend Sensors and OODA-DOM Modern applications are no longer static. SPAs, PWAs, and WASM pages contain valuable behavioral signals. OODA-HTTP introduces OODA-DOM: a frontend extension where the DOM (Document Object Model) acts as a live sensor of threat context. 16.1 DOM as a Radar Frontend components can observe: - Navigation patterns and rage clicks - Unexpected JavaScript injections or anomalies - Time-based interaction irregularities - Repeated DOM mutations from the same origin These observations are encoded in client OODA-Action headers or POSTed to telemetry endpoints. 16.2 DOM Score and Visualization The browser computes a DOM-specific score: - DOM entropy - DOM event deviation - DOM injection suspicion A local radar-style UI may freeze the screen or show a challenge. 16.3 Coordinated Frontend-Backend Loop The DOM extends the Observe phase. When aligned with backend OODA- Action, both actors co-evolve: - Client adjusts UI/reactivity - Server adjusts trust/session control This loop builds full-stack cognitive defense. The UI becomes a trusted sensor. OODA-HTTP is the first protocol where frontend activity contributes to protocol-level defense. UX and security merge into one loop. 17. OODA-DOM Good Practices Map DOM observability depends on disciplined frontend engineering. This map defines secure best practices for DOM instrumentation. 17.1 Mapping Sensitive DOM Zones Monitor areas such as: - Login/authentication forms - Payment input fields - Focused elements with unusual timing - Listeners tied to user input (click, submit, input) 17.2 Local DOM Score Buffering Buffer DOM threat scores in memory/session. Never persist to disk. Use thresholds to trigger server sync or visual feedback. 17.3 User Privacy and Transparency Show UI hints when DOM abuse is detected (e.g., clipboard hijack). Never export DOM structure without consent or policy. 17.4 Client-Side Actions Allowed local responses include: - Blur sensitive fields - Trigger a CAPTCHA - Delay UI response - Block input events 17.5 Coordination with Server If OODA-Action includes "dom-sync", enforce lockstep validation to ensure client-server agreement. This map forms the basis of trusted DOM security. OODA-DOM is not only detection - it is secure collaboration. 18. State Memory and Client-Side Persistence OODA-HTTP introduces adaptive memory at multiple layers. On the client, persistence helps maintain continuity of threat awareness. 18.1 Session vs Persistent Memory - Session Memory: Stores DOM scores, behavior traces, or OODA-Action feedback for a single session. - Persistent Memory: Optionally stores known safe patterns or recurring anomalies across sessions. Recommended scopes: - In-memory (volatile, privacy-safe) - sessionStorage (cleared on tab close) - IndexedDB (with expiration and scope) 18.2 Cookies and Namespaced Fields OODA-specific cookies may be used, if: - Marked HttpOnly, Secure, and SameSite - Prefixed with `ooda_` (e.g., ooda_ctx, ooda_score) - Short- lived and rotated regularly 18.3 Synchronization with Server Memory Client memory may sync with server via: - XHR beacon (DOM vector update) - WebSocket ping (score deltas) - OODA-Action header with trace summary 18.4 Privacy and Expiry All client memory must: - Respect user privacy settings and legal rules (e.g., GDPR) - Expire unless renewed via active interaction - Never store passwords or raw keystrokes In OODA-HTTP, memory builds trust. It is not a tool of surveillance. 19. Server-Side and Component-Based Integration OODA-HTTP is framework-agnostic and supports modular or component- driven systems such as microservices or SSR libraries. 19.1 Modular Backend Integration Each OODA phase maps to a module: - ooda_observe.c: Extracts metadata and behavior - ooda_orient.c: Scores via SVDD/PSLPSO or rules - ooda_decide.c: Applies policy and selects action - ooda_act.c: Enforces (headers, delays, blocks) - ooda_memorize.c: Stores history and context - ooda_cooperate.c: Interfaces with DOTS, STAMP Modules may run standalone or as a pipeline (e.g., on the edge). 19.2 Component-Level Embedding For SSR or hybrid stacks (Next.js, Astro, Django): - Add OODA middleware to routes - Annotate UI components with threat flags - Propagate scores into session context - Delay rendering on trust anomalies (DOM or TLS) 19.3 Reactive Architecture Patterns Reactive components can: - Parse OODA-Action headers per request - Adapt behavior (e.g., throttle, mask features) - Trigger DOM hooks for OODA-DOM sync OODA-HTTP wraps business logic with adaptive defense, without changing core semantics across SSR/CSR/hybrid architectures. 20. OODA Engine Requirements and Incremental Models Unlike traditional rule-based engines, the OODA engine is incremental, memory-aware, and built for adaptation - not static logic. 20.1 Minimum Requirements An OODA-HTTP engine MUST: - Process requests across 4+ phases (Observe -> Cooperate) - Maintain contextual state (trace, memory, scoring) - Support rule-based and score-based decisions - Accept dynamic rule updates (JSON, hot reload) 20.2 Incrementality as Doctrine Incrementality is foundational - not optional. An OODA engine MUST: - Load new rules without restart - Adapt behavior to recent session context - Learn new patterns from adversary behavior This requires: - Appendable memory modules - Modular, versioned rules - Scores influenced by past traces 20.3 Execution vs Knowledge The engine separates logic and knowledge: - ooda_engine.c: core execution loop - ooda_registry.json: knowledge base - ooda_score.json: session memory - ooda_cooperate.c: inter-agent logic This allows modular testing and external model training. 20.4 Commentary: Doctrinal Law Rule #1: You don't code a defense. You model the real. A static system defends what it knows. An OODA engine defends what it learns. The OODA-HTTP engine is not a firewall. It is a loop - adaptive, temporal, and adversary-aware. 21. Security Considerations OODA-HTTP is designed as a security extension for HTTP. Implementations must consider the confidentiality of telemetry exchanged with the OODA engine, and the risk of false positives leading to denial of service. 22. Requirements Language 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. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC9000] Iyengar, J. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021. [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, June 2022. [RFC9113] Thomson, M., et al., "HTTP/2", RFC 9113, June 2022. [RFC9114] Bishop, M., "HTTP/3", RFC 9114, June 2022. 12.2. Informative References [RFC9132] Mortensen, A., et al., "DDoS Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, September 2021. [RFC9244] Boucadair, M., et al., "Template for DOTS Signal Channel Extensions", RFC 9244, August 2022. [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [DOM] W3C, "Document Object Model (DOM)", https://www.w3.org/DOM/ [QUIC-LB] Duke, M., "Load Balancers for QUIC", draft-ietf-quic-load-balancers-21, IETF Work in Progress, July 2025. [SIEM] Gartner IT Glossary, "Security Information and Event Management (SIEM)", 2024. https://www.gartner.com/en/information-technology/glossary/siem [STAMP] Leveson, N., "Engineering a Safer World: Systems Thinking Applied to Safety", MIT Press, 2011. [SVDD] Tax, D., and Duin, R., "Support Vector Data Description", Machine Learning, 54, 45-66, 2004. [PSLPSO] Du, Z., "An Enhanced Particle Swarm Algorithm with Self-learning Strategy for Model Optimization", Springer Journal of Information Science, Vol. 60, 2023. Appendix A. Developer Guidance This appendix provides practical advice for developers implementing or integrating OODA-HTTP modules, headers, and logic in real-world systems. A.1 Header Parsing Clients and servers should parse the `OODA-Action` header as JSON. Use robust parsers with schema validation to avoid malformed input. Unknown fields MUST be ignored unless explicitly defined by policy. A.2 Stateless vs Stateful Modes Start with a stateless deployment to evaluate impact. Enable memory modules (e.g., Memorize, Adjust) once behavioral baselines are learned. Stateful modes require secure storage of session traces and scores. A.3 Integration Points OODA-HTTP can be integrated at: - Reverse proxies (e.g., NGINX, Envoy) via middleware - Application servers via request/response filters - Frontend DOM (via OODA-DOM module) - CDN or edge layers for pre-screening traffic Choose the point that balances latency, visibility, and control. A.4 Debugging and Observability Expose debug headers or logging modes for development. Example: OODA-Debug: score=88, vector=23f..., model=svdd_v2 Track model version, thresholds, and source of decision (e.g., proxy vs origin). Use structured logs for telemetry fusion and anomaly tracing. A.5 Fallback Mechanisms If the engine is unavailable, default to a safe policy (e.g., allow). Ensure fallback paths are well-defined to prevent denial of service from internal errors or misconfigurations. A.6 Rate Limiting and Cost Control Scoring and model execution can be expensive. Use rate limiting or sampling to reduce computational load. Prioritize high-risk sessions or unusual patterns for deeper inspection. A.7 Compatibility Tips Ensure compatibility with: - HTTP/1.1: plain text headers, no multiplexing - HTTP/2 and 3: multiplexed requests, header compression (HPACK/QPACK) - Intermediaries: proxies must forward or merge headers carefully Respect header case-insensitivity and header field size limits. A.8 Security Hardening - Sanitize all input before scoring - Enforce strict JSON schema - Limit memory retention periods - Protect scoring models and training data Security of the engine is critical - attackers may attempt to mislead or poison decision logic. Appendix B. Unified OODA Action Registry This registry defines the standardized values and fields for the `OODA- Action` header. It serves as a reference for implementers to ensure interoperability across modules, vendors, and deployments. B.1 Core Fields Each `OODA-Action` header MUST contain: - score (integer) - Range: 0-100. Indicates threat level. - category (string) - Classification of context. - action (string) - Recommended response. - timestamp (string) - ISO 8601 UTC time of decision. Optional fields: - origin (string) - Component that issued the decision. - confidence (string) - Confidence: 'low', 'medium', or 'high'. - reason (string) - Short tag explaining the logic path. - vector_id (string) - Reference to semantic vector used. - model (string) - Version or name of decision engine. B.2 Standard Categories The following categories are RECOMMENDED: - normal - No unusual behavior. - suspicious - Deviation from known safe behavior. - malicious - Confirmed harmful intent. - burst - High frequency or volumetric pattern. - low-rate - Slow connection or resource exhaustion. - bot-camouflage - Mimicking human patterns with intent to evade. - unknown - Unclassified or model-inconclusive. B.3 Standard Actions The following actions are defined: - allow - Permit the request normally. - block - Reject request at HTTP level. - throttle - Apply rate limit or introduce latency. - challenge - Enforce CAPTCHA, MFA, or puzzle test. - isolate - Route to sandbox, honeypot, or degraded path. - log - Flag for audit without enforcement. - escalate - Send to human operator or SIEM system. - retry - Ask client to retry with modified payload. - reroute - Divert request to alternate backend. B.4 Extensibility Notes - New categories and actions MUST be registered or namespaced. - Use prefixes (e.g., `x-orgname-action`) for private extensions. - Parsers MUST ignore unknown fields unless policy requires otherwise. B.5 Example OODA-Action: { "score": 93, "category": "bot-camouflage", "action": "challenge", "origin": "reverse-proxy-uk1", "confidence": "high", "timestamp": "2025-07-08T18:02:40Z", "reason": "rotating user-agent with no Referer header" } Authors' Addresses Rachid Bouziane SecRoot.io Villa El Majd 171, Tamsna Temara Rabat, Morocco Email: contact@secroot.io Expires: March 16, 2026