Skip to content

ADR 0020 — MÓDULO RELAY.Art — Bridge OOBI ↔ Customer MGMT

  • Status: Accepted (formalized 2026-05-12 with v3.7.0 — scaffolds shipping in v3.7.0)
  • Date: 2026-05-10
  • Deciders: TLSStress.Art project
  • Targets: v5.0 (Phase 1 Materialization scaffolds: RELAY-1..3 already merged Wave 4)
  • Patent claim family: claim #5 (RELAY bridge with PII strip + read-only default)

Context

ADR 0019 (OOBI VXLAN Fabric) defines OOBI as a closed overlay — DUTs and customer-side switches never join. But the bench still needs to: 1. Ingest telemetry from customer-side gear (NetFlow, Syslog, SNMP traps from the DUT MGMT NIC) 2. Egress control to customer-side gear when operator authorizes (SSH polls, SNMP polls, REST calls, NETCONF push)

A direct OOBI ↔ customer-MGMT bridge would violate the trust zones. The decision: introduce a dedicated MÓDULO that bridges only at the MGMT layer, never touches data plane, defaults to read-only, and PII-scrubs all ingress.

Decision

Introduce MÓDULO RELAY.Art as the sole MGMT bridge between OOBI and customer-side gear.

Topology

┌─ OOBI overlay (TRUSTED) ─┐       ┌─ Customer MGMT (UNTRUSTED) ─┐
│                          │       │                              │
│  Infra VIP (.100)        │       │  NGFW MGMT NIC               │
│  Other MÓDULOs           │       │  Customer switch MGMT        │
│        │                 │       │  Customer router MGMT        │
│        │ vxlan0          │       │        │                     │
│        ▼                 │       │        ▼                     │
│  ┌─────────────────────┐ │       │ ┌─────────────────────┐     │
│  │ RELAY.Art .240/.241 ├─┼───────┼─┤ relay-mgmt iface     │     │
│  │ (HA pair)           │ │       │ │                     │     │
│  └─────────────────────┘ │       │ └─────────────────────┘     │
└──────────────────────────┘       └──────────────────────────────┘
   vxlan0 (OOBI side)                 eth1+ (customer MGMT side,
                                       dedicated NIC per customer)

Hard rules

  1. RELAY toches MGMT only — never data plane. OSPF/BGP/SDWAN routers that peer with the bench do so via their own data-plane VLANs (e.g. VLAN 2809 for BGP peering link), NEVER via MGMT.
  2. Read-only default. All credentials in the RELAY vault are classified — READ-only creds are auto-loaded; WRITE creds require operator unlock window (per SSH-6 pattern).
  3. PII strip on ingress. Every NetFlow/Syslog/SNMP-trap record passes through a redactor before reaching the bench:
  4. K-anonymity ≥ 10 enforced on src_ip / dst_ip
  5. User-Agent + email-like patterns scrubbed
  6. Per-record audit hash for compliance
  7. Vault-isolated per-target credentials. RELAY's secrets store namespaces credentials per customer DUT; cross-customer leak surface = zero.
  8. DOM-aware. In production mode RELAY is auto-forced to read-only regardless of operator intent. Override requires DDPB chain unlock + audit reason.

Component layout

Component Function
relay-bridge (multi-NIC pod) dual-stack interface: vxlan0 (OOBI) + eth1+ (per-customer MGMT)
relay-vault per-target cred isolation; READ vs WRITE classification
ingress-redactor PII strip + k-anonymity enforcement before telemetry hits bench TSDB
egress-orchestrator SSH/SNMP-poll/REST/NETCONF clients; DOM-aware mode check
discovery-probe passive observation for VALIDATOR ML cortex (zone-tagged samples)

HA pair

Slots .240 (primary) and .241 (standby). Active-passive failover via leader election on OOBI overlay. Failover < 5s; state replicates via VALIDATOR's ML cortex shared store.

Architecture

Ingress flow (telemetry)

DUT NetFlow → relay-bridge eth1 → ingress-redactor (PII strip)
            → vxlan0 → Infra VIP (.100) → FLOW.Art collector
            → bench TSDB

Egress flow (control)

operator @ dashboard → API → DOM-aware policy check
                          → relay-vault credential fetch (READ or WRITE)
                          → egress-orchestrator
                          → eth1 → customer MGMT
                          → DUT response
                          ← egress audit log (every command + every response)

Discovery flow (passive observation)

relay-bridge sniffs eth1 ingress (passive) → discovery-probe
                                          → zone-tag samples (CUSTOMER zone)
                                          → vxlan0 → VALIDATOR ML cortex
                                          → fleet topology graph

Consequences

Pros

  • Trust zone discipline preserved (per ADR 0019)
  • PII compliance built-in (LGPD/GDPR k-anonymity ≥ 10)
  • Cross-customer credential isolation
  • DOM-aware production-mode hardening
  • Discovery feeds VALIDATOR ML cortex without OOBI exposure
  • Patent moat: RELAY = claim #5 in DOM/OOBI family

Cons / risks

  • HA failover adds 5s telemetry gap during transition
  • Per-customer NIC requirement at scale = NIC cost
  • PII redactor is irreversible — if bench needs source data for forensics, can't recover post-strip (mitigation: forensic hold flag bypasses redactor with explicit audit reason)

Compatibility

  • Existing bench deploys without RELAY → telemetry sources fall back to direct OOBI access (insecure; flagged in pre-flight)
  • Multi-customer benches → require RELAY mandatory (single-customer airgap labs may waive)

References

  • Memory: discuss_module_relay_art_2026_05_10.md
  • Memory: discuss_oobi_immutable_gateway_art_2026_05_10.md
  • Code: k8s/oobi/60-relay-art.yaml (RELAY-1 scaffold, Wave 4)
  • ADR cross-ref: 0019 (OOBI VXLAN fabric), 0018 (Compliance — LGPD/GDPR requirements)
  • Patent claim: #5