Skip to content

ADR 0010 — Inspection Profile: 5 named NGFW deep-inspection presets, RFC 9411-aligned

  • Status: Accepted
  • Date: 2026-05-08
  • Deciders: TLSStress.Art project
  • Targets: v4.5 (Cisco FTD MVP); v4.6 (Palo Alto + combined plan with Branch Office)

Context

Every NGFW under test exposes a long list of independent inspection dials — TLS decrypt, IDS/IPS, anti-malware (AMP), URL filtering, application identification, file inspection, sandbox / dynamic analysis, DNS security, CASB, etc. Throughput, p99 latency, and CPS budget all collapse non-linearly as more dials are turned on. Two separate problems result:

  1. Reproducibility across vendors and engagements. "Deep inspection was on" is not a benchmark statement. Cisco FTD's "Balanced Security and Connectivity" preset, Palo Alto's "Strict Security Profile", and Fortinet's "default UTM profile" all enable different dials. Two engineers running "the same" test on different vendors are measuring different things. Customers comparing vendor-A and vendor-B reports cannot make decisions from the numbers alone.

  2. Headline number selection bias. Vendor datasheets quote throughput from the lightest possible inspection setting (often "App-ID only" or "no TLS decrypt"). Customers planning capacity from those numbers discover the production cost only after deployment. The test bench needs to publish the cost of each major dial so capacity planning is grounded.

The v4.4 Branch Office Simulation (ADR 0008) added bandwidth shaping at the WAN edge, which is one half of "production realism". The other half is a credible inspection-stack profile. Without both, the bench publishes either a datacenter number with light inspection (vendor datasheet re-statement) or a branch number with no inspection (also unhelpful).

External alignment opportunity: RFC 9411 ("Benchmarking Methodology for Network Security Device Performance", March 2023, authored jointly by EANTC AG and the NetSecOPEN consortium) §6 enumerates the same dials the test bench needs to control. Aligning our profile vocabulary with RFC 9411 produces three dividends:

  • Customer reports can be cross-referenced against any NetSecOPEN-certified vendor report (e.g. the Cisco FPR-3105 / UNH IOL October 2024 report), giving customers a third-party comparison anchor.
  • Annex K (this work) can attest "this run satisfies RFC 9411 feature set X" as a verifiable claim.
  • Future certification (Sales Engineering credibility, NetSecOPEN membership in v5.x) is a continuation of the same vocabulary, not a rewrite.

Decision

Introduce 5 named Inspection Profiles as the operator-facing dial set. Each profile is a fixed bundle of feature toggles applied to the NGFW under test before agents launch and removed at run cleanup. Profiles are vendor-agnostic in name; the per-vendor mapping lives in implementation scripts (scripts/ip-apply-<vendor>.sh).

Cisco FTD is the MVP target for v4.5; Palo Alto Networks lands in v4.6 together with a "combined" plan that overlays Inspection Profile on Branch Office Simulation (the realistic enterprise scenario).

The 5 profiles

Profile Intent RFC 9411 §6 reference set
minimal L3/L4 ACL only — the throughput ceiling. Equivalent to "firewall mode without UTM" in vendor datasheets. None — establishes the baseline RFC 9411 calls "L4 firewall throughput"
balanced TLS decrypt on + IDS/IPS at vendor-default sensitivity. Closest to RFC 9411 "HTTP/HTTPS Throughput with IPS" benchmark. TLS Inspection ✓ · IDS/IPS ✓
paranoid Maximum inline inspection: TLS decrypt + IPS at strict + AV / anti-malware + URL filter + file inspection (file-type and signature only, no detonation). TLS Inspection ✓ · IDS/IPS ✓ · Anti-Malware ✓ · App Control ✓ · URL Filtering ✓
compliance Pinned subset for environments that must show specific dial states for an audit. PCI-DSS-style: TLS decrypt + IPS + AV + URL filter; logging at maximum verbosity; sandbox OFF (data residency). TLS Inspection ✓ · IDS/IPS ✓ · Anti-Malware ✓ · URL Filtering ✓ · max-log-verbosity (extension)
sandbox Slowest of the five: paranoid + on-box file detonation / dynamic analysis. Throughput collapses; useful for understanding the cost of deep file inspection. All paranoid dials + Anti-Malware in detonation mode (extension over RFC 9411 §6)

The five-profile choice is deliberate. Two profiles (e.g. "off / on") hide too much; ten profiles make customer comparison combinatorially intractable. Five matches the cardinality of vendor preset libraries (FTD ships 4 IPS policies; Palo Alto ships 5 Strict→Permissive templates) and is the cap before the X-axis of vendor-vs-vendor comparison charts becomes unreadable.

Profile feature matrix

The full dial set is fixed at this matrix; vendor implementations map each cell to vendor-specific configuration.

Dial minimal balanced paranoid compliance sandbox
L3/L4 ACL ✓ ✓ ✓ ✓ ✓
TLS Inspection ✓ ✓ ✓ ✓
IDS/IPS default strict strict strict
Anti-Malware (signature) ✓ ✓ ✓
Anti-Malware (detonation) ✓
App Control ✓ ✓
URL Filtering ✓ ✓ ✓
File Inspection ✓ ✓ ✓
DNS Security
Logging verbosity std std std max max

Conscious omission: DNS Security is not enabled in any profile. The test bench does not yet emit realistic DNS query patterns from the agents; turning on DNS Security would measure the vendor's response to synthetic-low-volume queries, which is misleading. DNS Security joins the matrix in v4.7+ when the agent fleet exposes a DNS query rate parameter (per the NetFlow / IPFIX work tracked separately).

RFC 9411 mapping per profile

RFC 9411 §6 ("Recommended Test Setups for NGFW Performance") enumerates 13 features that an NGFW MAY enable for a given benchmark run. The 5 profiles map onto subsets of that enumeration so a customer reading both a TLSStress.Art Annex K and an RFC 9411-aligned vendor report can cross-reference:

RFC 9411 §6 feature → TLSStress.Art profile inclusion
  TLS Inspection                 → balanced, paranoid, compliance, sandbox
  IDS/IPS                        → balanced (default), paranoid+ (strict)
  Anti-Malware                   → paranoid, compliance, sandbox
  App Control                    → paranoid, sandbox
  URL Filtering                  → paranoid, compliance, sandbox
  File Inspection                → paranoid, compliance, sandbox
  Logging                        → all (verbosity differs)
  DNS Security                   → none (deferred to v4.7+)
  Web Application Firewall       → none (out of scope, app-layer only)
  Data Loss Prevention           → none (requires content corpus, deferred)
  CASB                           → none (cloud-bound, out of scope)
  Sandboxing                     → sandbox (only)
  TLS 1.3 Decryption             → balanced, paranoid, compliance, sandbox
                                   (folded under TLS Inspection — TLS 1.3
                                    decryption is the only thing the bench
                                    does, since TLS 1.2 was deprecated by
                                    project policy in v3.6)

Reference comparison: Cisco FPR-3105 NetSecOPEN report (Oct 2024)

The Cisco FPR-3105 report tested at UNH IOL Class M (RFC 9411 medium-DUT class, 234 ACL rules, ~5 Gbps target). Its feature mix overlaps with balanced and a subset of paranoid:

FPR-3105 NetSecOPEN test TLSStress.Art profile equivalent
HTTP CPS (no inspection) minimal
HTTPS CPS (TLS decrypt + IPS) balanced
HTTPS Throughput (TLS + IPS + AMP + URL filter) paranoid (without App Control / sandbox)
Application Mix (Healthcare / Education) not yet — traffic mixes are a v4.7+ extension

This mapping is reproduced in Annex K of every run report so the customer can compare a TLSStress.Art number against the corresponding NetSecOPEN-certified number without doing the translation themselves.

Cisco FTD vendor mapping (v4.5 MVP)

For each profile, the operator script scripts/ip-apply-ftd.sh issues this configuration via the FMC REST API (or FDM REST API, whichever the device exposes):

Profile        FTD Access Policy  FTD IPS Policy    File Policy        URL Category   AMP
─────────────  ─────────────────  ────────────────  ─────────────────  ─────────────  ─────────
minimal        Allow-Trust        none              none               none           off
balanced       L4-and-Inspect     Balanced (default) none               none           off
paranoid       L4-Inspect-Block   Security (strict) Block-Malware      Block-Threats  inline
compliance     L4-Inspect-Audit   Security (strict) Block-Malware      Block-Threats  inline
sandbox        L4-Inspect-Block   Security (strict) Block-Malware-AMP  Block-Threats  Capacity Mode

(Names are FTD-canonical preset names; the apply script asserts each name resolves to a recognized policy ID before issuing the change. A mistyped or vendor-removed preset fails the apply, never silently applies a wrong policy.)

The verifier script scripts/ip-verify-ftd.sh reads the running policy state from FMC and asserts the (Profile, Policy) pair matches the table above. Mismatches block the run.

Annex K — new attestation section

Per-run, the report builder emits Annex K — Inspection Profile Attestation:

report.inspection_profile:
  applied: bool                # false → run was minimal-or-no-IP, omit annex
  profile_name: string         # one of: minimal | balanced | paranoid | compliance | sandbox
  vendor: string               # cisco-ftd | palo-alto | ...
  rfc9411_features: [string]   # e.g. ["TLS Inspection", "IDS/IPS"]
  expected_dials:              # the matrix row for this profile
    tls_inspection: bool
    ids_ips: "off" | "default" | "strict"
    anti_malware_signature: bool
    anti_malware_detonation: bool
    app_control: bool
    url_filtering: bool
    file_inspection: bool
    logging: "standard" | "max"
  observed_dials:              # read from the device via vendor API
    # same shape as expected_dials
  drift: [string]              # dials where expected ≠ observed (gates run)
  netsecopen_cross_ref:        # narrative pointer for customer-facing comparison
    classification: "RFC 9411 §6 subset"
    nearest_published_test: string  # e.g. "FPR-3105 HTTPS Throughput"
  attestation_sha256: string

Like Annex G (air-gap) and Annex J (Branch Office), the attestation is produced before the run and re-validated at the end. Drift between expected and observed dials blocks the run in production gating.

Consequences

Positive

  • Vendor comparisons become tractable. Same 5 profile names across FTD, Palo Alto, Fortinet, Check Point. Customer-facing reports publish numbers under each profile so the dial-cost is a chart row, not buried in body text.
  • RFC 9411 alignment is a tactical win available now. Annex K publishes the RFC 9411 §6 feature subset for every run. Customers cross-referencing with a NetSecOPEN-certified vendor report (e.g. FPR-3105) get the comparison without a translation step.
  • Capacity planning gets the cost-of-each-dial broken out. Running minimal → balanced → paranoid on the same plan answers "how much did TLS decrypt cost?" and "how much did adding IPS to TLS decrypt cost?" as discrete numbers.
  • Combined v4.6 plan (Branch Office × Inspection Profile) becomes a clean 2D matrix experiment without further design work — the two ADRs (0008 + this) are explicitly orthogonal so far as the test bed is concerned.

Negative

  • Every new vendor adds an apply/verify/rollback script. v4.5 is Cisco FTD only; v4.6 adds Palo Alto. Each vendor's dial mapping is bespoke, not derivable from the matrix. This is unavoidable — the alternative ("just send vendor configs verbatim") destroys the cross-vendor comparison story.
  • Per-vendor policy preset names are version-fragile. A vendor software upgrade can rename a built-in policy. Mitigation: the apply script resolves preset names to IDs at apply time and fails loudly on resolution miss; the verifier compares observed dial state, not observed preset names. So a vendor preset rename triggers a "preset not found, list of currently-shipped presets is X, Y, Z" error rather than a silent miscompare.
  • Initial implementation does not exercise the full RFC 9411 §6 matrix. DNS Security, WAF, DLP, CASB are deliberately deferred. Annex K must be honest about this — it lists every RFC 9411 §6 feature and marks deferred ones as "out of scope (this profile)" rather than implying coverage.

Neutral

  • Profile naming is not a published contract. Renaming is a one-time migration cost (scan catalog.yaml + dashboard UI strings). We commit to the 5-cardinality, not to the specific 5 strings, so if customer feedback shows "paranoid" reads pejoratively in a B2B context we can swap to "maximum" without ADR amendment.

Alternatives considered

Alternative A — Match vendor preset names verbatim (e.g. FTD's "Balanced")

Reject. Locks the test bench to one vendor's vocabulary. A multi-vendor report becomes "FTD: Balanced; Palo Alto: Strict Security Profile" — unreadable for the customer. The whole point of the abstraction is to normalize across vendors.

Alternative B — Match RFC 9411 §6 verbatim (no named profiles, just dial flags)

Reject. RFC 9411 §6 is a 13-flag matrix without bundling, which means 2¹³ = 8192 valid combinations. Operator UX collapses; report comparison charts become combinatorially unreadable. The profiles are bundles that map onto §6 subsets — RFC alignment without the operator-facing combinatorial explosion.

Alternative C — Two profiles only (off / on)

Reject. "Inspection on" is not informationally distinct from current practice. The whole point is to publish which dials and the cost of each subset. Two profiles cannot represent the cost surface.

Alternative D — Operator-defined profiles (free-form YAML dial sets)

Reject for v4.5; reconsider for v5.x. Free-form profiles destroy cross-engagement comparison: each customer's bespoke profile is incomparable with every other. The named-five model produces a shared-vocabulary commons. v5.x can introduce a free-form profile type alongside the named five, with the explicit caveat that free-form profiles do not appear in cross-customer comparison charts.

Implementation references

  • scripts/ip-apply-ftd.sh — Cisco FTD profile apply (PR-B v4.5)
  • scripts/ip-verify-ftd.sh — Cisco FTD profile verify (PR-B v4.5)
  • scripts/ip-rollback-ftd.sh — Cisco FTD profile cleanup (PR-B v4.5)
  • dashboard/src/lib/test-plan-loader.ts — schema extension environment.inspection_profile (PR-C v4.5)
  • dashboard/src/lib/inspection-profile/index.ts — TS wrapper around the bash scripts (PR-C v4.5)
  • dashboard/src/lib/preflight/inspection-profile-checks.ts — preflight check (PR-C v4.5)
  • dashboard/templates/annex-k-inspection-profile.md.tmpl — report annex (PR-D v4.5)
  • dashboard/src/lib/preflight/environmental.ts — composer wiring (PR-D v4.5; module already exists from v4.4)
  • docs/INSPECTION_PROFILE.md (+ .pt-BR.md, .es.md) — Operator-facing methodology (this PR)

Palo Alto vendor mapping + the combined Branch-Office × Inspection-Profile plan land in v4.6.

References

  • RFC 9411 — Benchmarking Methodology for Network Security Device Performance (Informational, March 2023; obsoletes RFC 3511; authored by EANTC AG + NetSecOPEN). §6 "Recommended Test Setups for NGFW Performance" is the dial enumeration this ADR aligns with.
  • Cisco FPR-3105 NetSecOPEN report (UNH IOL, October 2024) — the reference NetSecOPEN-certified test report this ADR's profile matrix cross-references.
  • Cisco FMC REST API documentation — FTD policy presets and IDs used by the apply/verify scripts.
  • ADR 0007 — Public-Internet Realism (annex G — air-gap attestation; this ADR adds Annex K alongside G and J).
  • ADR 0008 — Branch Office Simulation (Annex J; orthogonal to this ADR; combined plan in v4.6).
  • ADR 0009 — L2 BPDU isolation (Annex G layer 5; precedent for the 3-source attestation pattern reused by Annex K).

Amendment 1 — 2026-05-08 — Vendor roadmap, Cisco SR scope, global rules

This amendment was added after the original ADR was merged (PR #249) to encode three blocks of decisions that were taken in a follow-up scoping discussion:

  • the locked vendor roadmap for v4.5 → v4.7+
  • the Cisco Catalyst Secure Router scope (the in-scope SKUs and the explicit exclusions, with reasons)
  • two global rules that apply across every present and future vendor mapped by this bench

The original sections above remain authoritative for the methodology itself (the 5 profiles, the dial matrix, the RFC 9411 alignment, the Cisco FTD MVP). This amendment only extends scope.

A1.1 — Vendor roadmap (locked)

Release Vendor coverage Management plane
v4.5 (current) Cisco FTD (Firepower / Secure Firewall) FMC REST + FDM REST (dual support)
v4.6 Cisco Catalyst Secure Router 8100/8200/8300/8400 Catalyst SD-WAN Manager (vManage) REST API only
v4.7 reserved TBD (Palo Alto and/or Fortinet are the leading candidates)
v4.8 reserved TBD

Cisco IOS-XE autonomous mode is explicitly out of scope for any release, because the inspection feature set this ADR depends on (TLS decryption, Snort 3 IPS, Anti-Malware, App Control, URL Filtering) is gated behind Catalyst SD-WAN Manager and is not delivered by the autonomous-mode software image.

A1.2 — Cisco Catalyst Secure Router scope (v4.6)

Total in scope: 13 SKUs across 4 families, all generation-2 ("G2") hardware with no End-of-Sale announcement at amendment date.

Family In-scope SKUs
8100 (SD-WAN-capable only) C8131-G2 · C8151-G2 · C8151-CVAI-G2 · C8151-CVAP-G2 · C8161-G2
8200 Series C8235-E-G2 · C8231-E-G2 · C8235-G2 · C8231-G2
8300 Series C8375-E-G2 · C8355-G2
8400 Series (non-MX) C8455-G2 · C8475-G2

TLS decryption is hardware-accelerated on all 13 SKUs (confirmed at amendment date; the original 8100 datasheet calls TLS Decryption out explicitly, the 8200/8300/8400 datasheets fold it under "deep packet inspection / Threat Protection" without a per-feature line — vendor confirmation obtained 2026-05-08).

Explicit exclusions (with reasons)

Excluded Reason
C8130-G2 / C8130-VAI-G2 / C8130-VAP-G2 / C8140-G2 (4 base 8100 SKUs) No SD-WAN combo number in datasheet → no NGFW capability per Cisco product positioning
C8200L (a distinct product, NOT the C8200 Series) No TLS Decryption capability — easy to confuse with the Catalyst 8200 Series above; this exclusion is explicit to prevent drift
C8455-G2-MX Meraki Dashboard managed (Meraki MX 19.2 OS), separate API ecosystem; deferred to a possible later release
Cisco Catalyst 8500 series (C8550-G2, C8570-G2) DC / aggregation use case; threat-protection EMIX numbers not published; deprioritized
IOS-XE autonomous mode (any router) NGFW features gated behind Catalyst SD-WAN Manager — autonomous mode does not deliver them
ISR 1000 series, ISR 4000 series, Catalyst 8000V, Catalyst 8200 uCPE Outside the Cisco Catalyst Secure Router lineup, or virtual / uCPE form factor not in current DUT model

A1.3 — Telemetry source (locked for v4.6)

The v4.6 release will collect device telemetry primarily through Catalyst SD-WAN Manager (vManage) REST APIs — Real-Time Monitoring + Statistics endpoints. Direct device Syslog and gNMI streaming telemetry are secondary signals only. A separate ADR 0012 ("Telemetry Expansion") will codify the integration; it is a v4.6 prerequisite, not a v4.5 one.

A1.4 — Two global rules across all vendors

Both rules apply to every present and future vendor mapped by this bench, not just Cisco. They are repeated here so any future ADR amendment or per-vendor mapping document can reference them by number.

Rule G1 — No TLS decryption capability ⇒ not a DUT

Any product that cannot perform inline TLS decryption (in hardware or software) is excluded immediately. Why: the TLSStress.Art bench exists to measure TLS decryption performance; a SKU without inline TLS decrypt has nothing for the bench to measure. How to apply: verify TLS decryption is listed as a supported security service in the vendor's datasheet (or vendor support confirmation) before adding the SKU to the catalog. Already triggered the exclusion of C8200L above.

Rule G2 — No End-of-Sale or announced-EoS models

Any SKU with End-of-Sale, or with an EoS announcement (including future-dated EoS notices), is excluded immediately and stays excluded. Why: customers will not invest in performance-testing soon-to-retire gear; vendors stop publishing software updates after EoS, which makes benchmark numbers stop being comparable as firmware diverges across units in the field. How to apply: before adding any SKU to the catalog or running automation against it, check the vendor's lifecycle page —

  • Cisco: eox.cisco.com
  • Fortinet: lifecycle / product matrix
  • Palo Alto Networks: end-of-life summary
  • Check Point: K-numbers EoL portal
  • Juniper SRX: EOL portal (now hosted on HPE post-acquisition)
  • Sophos: lifecycle page (the XGS 1st-Gen Desktop line is currently flagged "as long as stock lasts" → counts as announced-EoS)
  • Forcepoint, WatchGuard: vendor-specific lifecycle pages

Re-verify before each release cut. If a SKU's EoS status changes mid-release, the catalog entry is moved to deprecated: true rather than deleted (preserves historical run reports that referenced it).

A1.5 — DUT Catalog dependency (forward reference)

This amendment introduces 13 Cisco Catalyst Secure Router SKUs and re-states the 9-vendor scope locked in the v4.5 PR-A2 work ("DUT Catalog"). The catalog is a separate, independent mechanism — operators select a DUT from the catalog regardless of whether per-vendor automation scripts exist for it. The integration tier is per-SKU:

  • full — apply / verify / rollback scripts work end-to-end
  • planned-vX.Y — automation deferred to a named future release
  • catalog-only — the operator configures the device manually; the dashboard captures DUT identification and datasheet baseline numbers in the run report

For the v4.6 release, all 13 Cisco Catalyst Secure Router SKUs ship at tier planned-v4.6 until PR-B/C/D of v4.6 lands, at which point they graduate to full.

Amendment 2 — 2026-05-08 — Two more global rules: G3 (TLS+DPI) and G4 (terminology)

This amendment adds two more global rules to the ones locked in Amendment 1 (G1: no TLS decryption ⇒ not a DUT; G2: no EoS / announced EoS). Both came up in the same scoping discussion that expanded the catalog to servers + switches + Huawei NGFW.

Rule G3 — TLS Inspection without DPI is not a valid test mode

Several NGFW vendors expose two distinct modes for what they loosely call "SSL Inspection" or "TLS Inspection":

  • A lightweight mode that only inspects the TLS handshake (server certificate, SNI, JA3 fingerprint). The encrypted payload is never decrypted. Performance numbers measured in this mode are 5-10× higher than real TLS Inspection — but the inspection is not actually happening at the application layer.

  • A full mode that performs MITM on the TLS session, decrypts the payload, runs DPI (Deep Packet Inspection) including IPS / Anti-Malware / URL filtering / file inspection on the cleartext, and re-encrypts to the client. This is what every other security vendor and every benchmark methodology means by "TLS Inspection".

Some vendors publish their performance numbers in the lightweight mode without disclosing the distinction. A customer comparing numbers across vendors gets a misleading apples-to-oranges picture.

G3 locks the rule: every TLSStress.Art test that exercises a non-minimal Inspection Profile MUST have the DUT configured in full TLS Inspection + DPI mode. The lightweight mode is never a valid test configuration on this bench.

The five Inspection Profiles from this ADR map onto G3 as follows:

Profile DPI required? Reason
minimal N/A No TLS inspection at all (baseline ceiling)
balanced ✓ MANDATORY TLS Inspection on; would be useless without DPI
paranoid ✓ MANDATORY Heavy inspection — DPI is the whole point
compliance ✓ MANDATORY Audit trail requires payload-level evidence
sandbox ✓ MANDATORY File detonation requires payload extraction

Per-vendor enforcement (the trap matrix)

Each vendor packages the lightweight vs full mode under different names. The per-vendor apply scripts (PR-B onward) MUST select the full mode and fail loud if asked to apply a TLS-inspection profile in the lightweight mode. Trap matrix as of 2026-05-08:

Vendor Lightweight (forbidden) Full DPI (required)
Fortinet FortiGate Certificate Inspection Deep Inspection
Cisco FTD (FMC/FDM/SCC) TLS Server Identity Discovery only Decrypt - Resign + AVC + IPS + Malware + URL
Palo Alto PAN-OS Decrypt - No Profile / Mirror only Decrypt + Decryption Profile + IPS + AV + URL
Check Point Quantum/Force HTTPS Categorization only Inbound/Outbound HTTPS Inspection + IPS + Threat Prevention
HPE Juniper SRX Application-First (no SSL Forward Proxy) SSL Forward Proxy + IDP + URL Filter + AV
Sophos XGS Web Protection without SSL/TLS Inspection SSL/TLS Inspection rules + Decrypt + IPS + AV
Forcepoint NGFW TLS Application Identification TLS Inspection + Deep Inspection + Anti-Malware
WatchGuard Firebox HTTPS Content Inspection only HTTPS DPI + IPS + Application Control + Gateway AV
Huawei NGFW TLS visibility without decryption SSL/TLS Decryption Policy + IPS + AV + URL

Annex K of every report attests the inspection mode actually read back from the device. If a run completes with the device in lightweight mode while a non-minimal profile was declared, the run is marked INVALID and the report cover prints a red flag — preventing the customer from publishing comparable-looking numbers that aren't comparable.

The full vendor-by-vendor trap detail (with screenshots, vendor doc URLs, and example misconfigurations to avoid) lives in docs/TLS_INSPECTION_TRAPS.md (en + pt-BR + es), shipped together with this amendment.

Rule G4 — Terminology: "TLS Inspection" always; "SSL Inspection" never

SSL 3.0 was broken in 2014 (POODLE attack). TLS 1.0 and 1.1 were deprecated by IETF in 2021 (RFC 8996). The IETF and NetSecOPEN both use "TLS Inspection" uniformly; vendor marketing material occasionally still uses "SSL Inspection" as a legacy product name.

G4 locks the rule: the TLSStress.Art project never originates the term "SSL Inspection" in any artifact under our control — docs, ADRs, runbooks, dashboard UI, error messages, commit messages, PR descriptions, code comments, report copy. The correct, IETF / NetSecOPEN- validated, market-standard term is "TLS Inspection".

Handling vendor literal text

Vendor datasheets occasionally use the deprecated "SSL Inspection" phrasing as the product name. The catalog YAML files normalize this:

  • Schema field names use only TLS terminology (tls_decryption, tls_decryption_hw_accel, tls_decryption_gbps).
  • Per-vendor seed YAML files carry a header note stating this catalog uses "TLS Inspection" uniformly; vendor datasheets occasionally use the deprecated "SSL Inspection" term — entries are normalized.
  • When directly citing a vendor's literal feature name (e.g. in docs/TLS_INSPECTION_TRAPS.md), the cite uses quotation marks + parenthetical translation, e.g. vendor calls this "SSL Forward Proxy" (TLS Inspection in the IETF / NetSecOPEN sense). This preserves traceability while never originating the deprecated term.

Consequences

Positive

  • Customer comparisons across vendors become meaningful. Two NGFWs with the same throughput number under G3-enforced testing are actually comparable, instead of one of them being a lightweight-mode number masquerading as full inspection.
  • Catches the trap automatically at test-run time. Annex K's inspection-mode read-back means an operator can no longer accidentally (or maliciously) ship a misleading number.
  • Project terminology aligned with IETF + NetSecOPEN — a small thing, but it positions the project as serious about industry standards. Customer reports can be cross-referenced against RFC 9411 / NetSecOPEN reports without translation overhead.

Negative

  • Per-vendor apply scripts (PR-B onward) become more complex — each script must know the vendor's preset names and refuse to configure the lightweight mode. The trap matrix above is the source of truth for that refusal logic.
  • Some vendors won't expose the inspection mode programmatically. In those cases the apply script must read back the resulting policy state from the device API and infer the mode (e.g. "if no Decrypt Profile attached, mode is lightweight, fail apply"). PR-B work item.

Neutral

  • Customers running the bench against an existing production NGFW may discover their NGFW was misconfigured all along — some customers have shipped lightweight-mode "TLS Inspection" to production by accident. The bench surfacing this is feature, not bug — but operators need to be ready to explain the surprise.