ACNA: Admitted Connection Network Architecture

Research and implementation repository for ACNA, a vendor-neutral, explicitly separated, failure-isolated admission controller that gates network access before unauthorized traffic reaches the enforcement firewall.

Project Structure

.
├── docs/                              # Documentation and research guides
│   ├── research-roadmap.md            # 7-phase research roadmap (overview)
│   └── research-foundation-summary.md # Summary of completed research foundation
│
├── research/                          # Research phase deliverables
│   ├── phase-1-priorart/              # Phase 1: Competitive analysis
│   │   └── prior-art-analysis.md
│   ├── phase-2-threat-model/          # Phase 2: Threat model formalization
│   │   └── threat-model.md
│   └── phase-3-benchmark/             # Phase 3: Benchmark design
│       └── benchmark-design.md
│
├── api/                               # Phase 4: API specification (TBD)
├── implementation/                    # Phase 5: Implementation planning (TBD)
├── cloudflare-integration/            # Phase 6: Cloudflare integration (TBD)
└── prototype/                         # Phase 7: Prototype & benchmarking (TBD)

Research Phases

Phase 1: Prior-Art Analysis ✅

Document: research/phase-1-priorart/prior-art-analysis.md

Determine what existing architectures already implement ACNA-like functionality. Identify ACNA's true distinguishing claims.

Phase 2: Threat Model Formalization ✅

Document: research/phase-2-threat-model/threat-model.md

Define precisely what threats ACNA addresses. Specify security properties that ACNA must guarantee. Create failure-mode taxonomy.

Key Content:

• 30+ specific threats (5 categories)
• 13 security properties (6 critical, 4 important, 3 performance)
• 6 attack scenarios
• Threat-to-property mapping

Phase 3: Benchmark Design ✅

Document: research/phase-3-benchmark/benchmark-design.md

Design an automated, reproducible benchmark that proves or disproves ACNA's claims.

Key Content:

• Test infrastructure architecture
• 24+ test scenarios (4 categories + performance)
• Pass/fail criteria (objective)
• Comparison baselines (NGFW, NAC, ZTNA)
• Test orchestrator specification

Phase 4: API Specification (Next)

Formally specify ACNA interfaces:

• Client API (authentication, session management)
• Firewall API (policy queries, token verification)
• Management API (revocation, configuration)
• Adapter API (vendor-neutral policy model)

Phase 5: Implementation Planning (Next)

Break down ACNA implementation into milestones. Prioritize features for MVP. Identify dependencies.

Phase 6: Cloudflare Integration (Next)

Investigate how ACNA fits into Cloudflare's security architecture.

Phase 7: Prototype Development & Benchmarking (Execution)

Build the MVP, run the benchmark, collect evidence.

Quick Start

1. Start here: Read docs/research-foundation-summary.md for an overview
2. Understand the roadmap: Review docs/research-roadmap.md (Sections 1-2)
3. Deep dive into threat model: Read research/phase-2-threat-model/threat-model.md
4. Understand what to build: Review research/phase-3-benchmark/benchmark-design.md

Decision Framework

Key Decision Points

Phase	Question	Input	Success Criteria
1	Is ACNA novel?	Prior-art research	≥1 distinguishing claim validated
2	Is threat model complete?	Threat model + security team review	Model is comprehensive
3	Can benchmark prove claims?	Benchmark design + test infrastructure	Benchmark can distinguish ACNA from alternatives
4	Is API implementable?	API specification	MVP API is ≤5 endpoints
5	Does MVP beat baseline?	Benchmark results	≥3 critical metrics show improvement
6	Is Cloudflare integration strategic?	Research + results	Clear value for both parties

Critical Success Factors

1. Benchmark must be falsifiable — Tests ACNA can fail; let data speak
2. Security properties must be testable — Every property has objective test + pass/fail
3. Honest positioning — Describe ACNA as architecture composition, not new primitive
4. Architectural separation must be real — ACNA failure ≠ firewall failure
5. Vendor neutrality must not be theater — Adapters for ≥2 firewalls; portable policy model

Resources

• Team: Security architect, 2x engineers, 0.5x DevOps, 0.5x PM, 1x QA (est. 5 FTE)
• Timeline: 16 weeks (MVP + benchmark)
• Infrastructure: Linux server(s), Docker, Kubernetes, Prometheus, Git

Status

• Research Foundation: ✅ Complete (4 research documents, 1 summary)
• Phase 1 (Prior-Art): Awaiting execution
• Phases 2-3: Designed, awaiting validation
• Phases 4-7: Planned, awaiting Phase 1-3 completion

Next Action

See docs/research-roadmap.md Section 2 ("Immediate Next Steps") for Week 1 activities.

---

Last Updated: 2026-08-21
Research Lead: [TBD]
Status: Research Foundation Complete; Ready for Phase 1 Execution