Production Architecture and Security Report: Two-Lane Direct P2P Seed Fleet for TinyRustLM

Full report

On this page

1. Scope, Assumptions, and Non-Goals

The following analysis details the production architecture, network security protocols, and operational parameters for the TinyRustLM and MiniModel direct Peer-to-Peer (P2P) seed host fleet. The architectural paradigm strictly enforces a decentralized model wherein TinyRustLM.com operates exclusively as the browser-based chat user interface, and MiniModel.org functions solely as the catalog and discovery surface. Neither project domain hosts, proxies, relays, or intercepts model byte streams. The overarching operational mandate requires that model bytes must flow directly between consenting, user-run peers via established Cross-Origin Resource Sharing (CORS) over direct HTTP connections. The system constraints dictate that a single operator fleet must support up to twenty distinct admitted model identities. Each model must be served by exactly two independently restartable OS-level process lanes. These are not multiplexed listeners spawned within a single monolithic process, but rather two entirely separate operating system processes that independently bind to network sockets and serve the same read-only artifact and piece store. This report assumes the operating environments are predominantly home and small-office networks subject to Network Address Translation (NAT), Carrier-Grade NAT (CGNAT), and stateful firewalls. The architecture assumes the host operates on a standard dual-stack (IPv4 and IPv6) operating system (Linux, macOS, or Windows) utilizing asynchronous Rust networking primitives. This report explicitly excludes the design of a relay network, STUN/TURN fallback systems, or any Hugging Face proxy configurations, as the direct CORS path is established as the sole intended production path. There is no provision for a project-site byte fallback mechanism. Furthermore, fabricating peer-health responses or utilizing loopback addresses to simulate public reachability are strictly out of scope and explicitly forbidden by the protocol's fundamental security invariants.

2. Process and Socket Architecture Diagrams

The requirement for exactly two independently restartable process lanes per model necessitates a highly resilient socket binding and memory management strategy. Because both lanes serve the exact same read-only model artifact, the primary architectural challenge involves preventing physical memory duplication and handling port binding collisions atomically without service degradation. The process architecture relies on a supervisor model wherein the fleet manager oversees up to forty independent worker processes (twenty models multiplied by two lanes). To ensure that a 925 MiB model does not consume 1.85 GiB of Random Access Memory (RAM) when served by two independent lanes, the architecture must utilize memory-mapped files. When multiple processes map the same file utilizing the MAP\_SHARED flag, the operating system kernel leverages its page cache to maintain a single view of the file in physical memory1. Both Lane 1 and Lane 2 possess separate virtual address spaces, but their Page Table Entries (PTEs) point to the exact same physical memory frames2. In the Rust ecosystem, crates such as memmap2 or mmap-io provide zero-copy memory-mapped file I/O capabilities, allowing the processes to request PROT\_READ and MAP\_SHARED protections3. Because the mapped files are strictly read-only, there is no risk of inter-process race conditions modifying the underlying model weights, rendering the memory sharing inherently thread-safe across process boundaries5.

Socket ownership and port binding present platform-specific challenges. On Unix-like systems (Linux and macOS), the SO\_REUSEADDR flag alters the way wildcard addresses are handled and permits binding to a port that is currently in the TIME\_WAIT state, which is crucial for rapid lane restarts9. However, if two completely independent processes attempt to bind to the exact same IP and port simultaneously, the second will fail unless SO\_REUSEPORT is used. Because the specification requires exactly two independently restartable process lanes representing distinct endpoints, port collision on the same lane's configured port must result in an atomic failure. The application must explicitly avoid SO\_REUSEPORT, as its inclusion would cause the kernel to non-deterministically load-balance TCP connections across completely different instances, violating the independent lane requirement11. Conversely, on Windows environments, SO\_REUSEADDR historically allowed malicious applications to hijack active ports, leading to non-deterministic packet routing12. Therefore, the Windows implementation must explicitly utilize SO\_EXCLUSIVEADDRUSE to ensure that once a lane binds to its port, no other local unprivileged user process can forcibly bind to it and intercept the P2P traffic12. The lifecycle of each lane process requires deterministic state handling. Each lane must exit immediately if any of its critical endpoint threads (such as the HTTP listener or the metrics aggregator) terminate unexpectedly. Implementing a graceful drain protocol ensures that during a managed shutdown, the lane closes its listening socket to reject new inbound SYN packets but maintains existing established connections for a configured grace period to allow in-flight chunk transfers to complete15. If a process crashes, the fleet supervisor must implement an exponential restart backoff algorithm (e.g., waiting 2, 4, then 8 seconds) to prevent infinite crash loops that could exhaust host CPU resources or file descriptors, while the secondary lane continues to serve the model unimpeded.

3. HTTP Protocol Profile with an Allow/Deny Table

Because the host exposes a port directly to the public internet, the HTTP server attack surface must be aggressively minimized. The implementation must adhere strictly to a heavily constrained subset of RFC 9110 (HTTP Semantics) and RFC 9112 (HTTP/1.1 Message Syntax and Routing)16. The endpoints must exclusively answer to GET requests for data retrieval and narrowly scoped OPTIONS requests for CORS preflight validation. All other HTTP methods, including POST, PUT, DELETE, TRACE, and CONNECT, must be rejected at the earliest parsing phase with a 405 Method Not Allowed response to eliminate state-mutating attack surfaces16. Furthermore, bounded headers are strictly required. The server must enforce maximum limits on header size (e.g., 8 KiB total) to prevent memory exhaustion attacks caused by infinitely long header streams. Request Smuggling, a class of vulnerabilities resulting from parser desynchronization between front-end and back-end HTTP infrastructure, is a primary threat when dealing with fragmented HTTP implementations19. According to RFC 9112 Section 6.1, if a request contains both a Content-Length and a Transfer-Encoding header, the server must prioritize Transfer-Encoding or reject the message19. For Version 0 of this P2P host, the safest architectural decision is a fail-closed paradigm: if a request contains Transfer-Encoding: chunked, or if it contains multiple, duplicate, or conflicting Content-Length headers, the host must immediately terminate the TCP connection without returning an HTTP response19. This deterministic connection close strategy permanently eliminates the ambiguity that fuels HTTP request smuggling.

Path traversal attacks represent a critical vulnerability for static file servers. The fleet serves an exact allowlist of fixed-name piece files, such as model.safetensors and status.json. The HTTP router must never construct local file paths by directly concatenating user-supplied URI input. Instead, the router should implement a strict dictionary mapping between requested URIs and pre-resolved, absolute canonical file paths on disk. If dynamic path parsing is strictly necessary, the application must utilize Rust's std::path::Path::components() to normalize the path and explicitly reject any path containing Component::ParentDir (..) or Component::RootDir (absolute paths)26. The router must proactively detect and reject percent-encoded traversal attacks (e.g., %2e%2e%2f), null-byte injections (%00), and Unicode homoglyphs, returning a 400 Bad Request before the operating system's filesystem API is ever invoked28. To defend against symlink and reparse-point evasion, where an attacker might place a malicious symlink in the model directory pointing to sensitive system files, the application must verify that the final canonicalized path resolves strictly inside the designated base directory boundary using fs::canonicalize30. Finally, strict MIME type enforcement must be applied, serving artifacts strictly as application/octet-stream and metadata as application/json with nosniff headers to prevent browser-based MIME confusion attacks.

4. Fleet Resource and Bandwidth Model

A single operator fleet running the maximum capacity of 20 distinct model identities, with two lanes per model, will spawn 40 distinct processes. Efficient resource scheduling is mandatory to prevent the host operating system from experiencing catastrophic resource exhaustion, specifically regarding disk I/O, file descriptors, and network bandwidth. Assuming a worst-case scenario where all 20 models are 925 MiB each, the total data footprint mapped into memory is approximately 18.5 GiB. Because the system relies on mmap(MAP\_SHARED), the OS page cache manages the translation between physical memory and the NVMe/SSD storage1. To prevent aggressive disk read amplification and thrashing, the host should utilize the posix\_fadvise system call. When a peer requests a cold model, the host can hint the kernel with POSIX\_FADV\_WILLNEED to initiate asynchronous readahead into the page cache2. Conversely, if the server detects sequential streaming of a large file that will not be reused immediately by other peers, issuing POSIX\_FADV\_DONTNEED behind the read cursor instructs the kernel to drop those specific pages, preventing the massive 18.5 GiB footprint from forcing the host OS to page out active application memory, which leads to Out-Of-Memory (OOM) conditions32. Bandwidth scheduling must guarantee fairness across all 40 lanes. If a home user has a 100 Mbps uplink, allowing unbounded concurrent peers will result in extreme TCP congestion collapse, causing massive packet loss and excessive HTTP timeouts. The system must enforce a global concurrency token bucket alongside per-lane connection limits. For instance, capping global active connections at 400, and per-lane connections at 10, ensures that each active connection receives a minimum theoretical throughput of 250 Kbps, preventing connection starvation. Upload bandwidth caps should be enforced at the application layer using a token bucket rate limiter wrapped around the asynchronous write streams, ensuring the fleet never saturates the host's physical uplink.

Metrics collection must remain useful without relying on a proprietary telemetry backend. The fleet should expose a local-only metrics endpoint (e.g., binding strictly to 127.0.0.1) that outputs standard Prometheus-formatted text. This allows advanced operators to scrape metrics regarding page cache hits, byte transfer rates, and peer connection durations, while ensuring absolute privacy and adherence to the decentralized constraint.

5. Reachability Taxonomy and Operator Workflow

Peer-to-Peer endpoints in home and small-office environments inevitably sit behind Network Address Translation (NAT) gateways and stateful firewalls. Reaching these peers from the outside network constitutes the primary operational hurdle of this architecture. The system must never silently modify a user's router or firewall configuration. Network security principles dictate that boundary changes require explicit operator consent and visibility. For the initial release policy, the recommended primary approach is Manual Port Forwarding mapped via the host OS firewall and the gateway router. If the user explicitly opts into automated mapping, the software should utilize the Port Control Protocol (PCP, RFC 6887), the modern successor to the NAT Port Mapping Protocol (NAT-PMP, RFC 6886\)36. PCP operates over UDP port 5351 and allows the host to explicitly request an external IPv4/IPv6 address and port mapping with a defined lifetime38. Universal Plug and Play (UPnP IGD) should be considered a legacy, secondary fallback due to its complexity and severe history of security vulnerabilities (e.g., allowing external IP spoofing to open arbitrary internal ports), but it remains highly prevalent in older consumer networking equipment38. Operators subjected to Carrier-Grade NAT (CGNAT) or Double NAT architectures (e.g., an ISP router feeding into a secondary mesh Wi-Fi router without bridge mode) cannot accept inbound connections via PCP or manual port forwarding. In these scenarios, operator-approved tunnels (such as WireGuard, Tailscale, or Cloudflare Tunnels) represent a valid networking configuration, provided the operator maps the tunnel endpoint directly to the local lane process. Reverse proxies are strictly evaluated: a reverse proxy is permissible only if it operates at Layer 4 (TCP passthrough) or transparent Layer 7, provided it does not cache, alter, or proxy the model byte stream in a way that violates the direct P2P constraint. To provide precise, actionable diagnostics via the Command Line Interface (CLI) and User Interface (UI), the state machine must assign the following strict taxonomy labels to every lane:

6. Canonical External-Proof Schema and Signature Procedure

Public announcements to the MiniModel.org catalog are strictly forbidden until an outside-network observer mathematically proves that both endpoints are publicly reachable. The observer queries the endpoint, verifies the byte hashes of the target artifacts, and returns a signed, expiring receipt bound strictly to the fleet and model identity. To prevent replay attacks, parameter tampering, and downgrade attacks, the payload must undergo strict JSON canonicalization (e.g., following RFC 8785\) prior to signing. The canonical receipt schema must explicitly include the fleet\_id and lane\_id to prevent cross-lane receipt theft. It must include the model\_id and the strictly normalized public URL, which involves stripping default HTTP/HTTPS ports, lowercasing the scheme and host, and completely resolving any . and .. segments according to RFC 3986 URL normalization standards40. The schema incorporates the artifact\_sha256 and piece\_set\_sha256 to prove the observer validated the correct data bytes. Furthermore, the checked\_routes array proves exact path validation, while the observer\_key\_id and implementation\_version trace the audit origin. Finally, issued\_time, observation\_time, and expiry bound the temporal validity, and a cryptographically secure nonce (or unique receipt\_id) prevents replay attacks against the catalog ingest endpoint. The observer signs this canonicalized JSON utilizing the Ed25519 digital signature algorithm (RFC 8032\)42. However, implementing Ed25519 securely requires strict adherence to scalar validation to prevent a cryptographic vulnerability known as signature malleability. The Ed25519 elliptic curve operates over a group order denoted as [Figure omitted from source export]. If a cryptographic verifier does not explicitly check that the scalar component [Figure omitted from source export] of the signature is strictly less than [Figure omitted from source export], an attacker can capture a valid signature [Figure omitted from source export] and forge a mathematically equivalent, valid signature [Figure omitted from source export]43. This malleability vulnerability (documented in CVE-2026-25793 and others) allows attackers to bypass signature uniqueness checks, replay tracking, and canonicalization validation, fundamentally compromising the integrity of the catalog43. To neutralize this threat, the fleet and the catalog must verify the observer's signature using the precise validation semantics outlined in Zcash Improvement Proposal 215 (ZIP-215), which is implemented in consensus-grade Rust crates such as ed25519-zebra or ed25519-consensus46. ZIP-215 semantics explicitly mandate the rejection of non-canonical [Figure omitted from source export] values (enforcing [Figure omitted from source export]), require the use of the cofactored verification equation ([Figure omitted from source export]) to ensure consistency in batch verification, and dictate the acceptance of non-canonical [Figure omitted from source export] and [Figure omitted from source export] points49. Clock skew between the observer and the fleet introduces a risk of premature receipt rejection. The protocol must enforce a standardized clock skew tolerance window (e.g., [Figure omitted from source export] seconds) when validating issued\_time. To mitigate downgrade attacks, all communications with the observer must strictly enforce TLS 1.3, rejecting any fallback to unencrypted HTTP or legacy cryptographic suites. Key rotation protocols dictate that the observer's public keys are distributed via an out-of-band root of trust, and compromised observer keys trigger immediate revocation lists. Future protocol iterations will implement a multi-observer quorum, requiring the endpoint to obtain signatures from [Figure omitted from source export] out of [Figure omitted from source export] geographically distributed observers, eliminating the single point of compromise associated with a monolithic observer.

7. Announcement/Revocation State Machine

The catalog eligibility state machine ensures that a failed or compromised lane cannot leave a stale endpoint advertised to the network. The system operates on an uncompromising fail-closed architecture. Upon initial startup and revalidation, the lane parses the local model artifact, binds its listener, and explicitly requests an external proof from the observer network. Until the signed receipt is received and verified, the lane remains locally functional, but its internal state is set to Announcement Eligible \= false. Once the valid receipt is applied, the fleet supervisor transmits the payload to the catalog, transitioning the state to Advertised. Environmental changes trigger immediate state transitions. If the Dynamic Host Configuration Protocol (DHCP) lease expires and the host's public IP changes, triggering a URL rotation, or if the operator explicitly initiates model removal, the existing observer receipt is immediately flagged as invalid by the fleet supervisor. A distinct revocation payload, signed by the fleet's private Ed25519 key, is pushed to MiniModel.org, transitioning the catalog state to Revoked. Because observer receipts include a strict expiry timestamp, the fleet supervisor proactively requests a new proof from the observer network five minutes prior to expiration (receipt drift mitigation). If the observer is unreachable or the host's network has dropped, the fleet fails to renew the proof. The receipt expires locally, and the catalog natively drops the endpoint via its own internal Time-To-Live (TTL) mechanism, resulting in a Stale state. Crucially, the system is explicitly designed for two independent lanes. If Lane 1 suffers an Out-of-Memory (OOM) crash, a thread deadlock, or a disk I/O stall, the fleet supervisor detects the dead process. It generates a partial revocation specifically for Lane 1 and pushes it to the catalog. Lane 2 remains fully functional, and its independent URL remains Advertised. Because the lanes are logically and physically decoupled, the failure of one does not taint the eligibility or reachability of the other.

8. Threat Model

A comprehensive threat model encompasses attacks originating from remote network peers, malicious artifact metadata, compromised infrastructure observers, and local unprivileged users.

Remote Peers (Network Attacks)

Malicious network peers frequently attempt resource exhaustion attacks. In a Slowloris attack, an adversary opens hundreds of concurrent TCP connections and sends HTTP request headers at a drip-feed rate of one byte per second, keeping the sockets alive indefinitely and starving legitimate peers51. Because this attack utilizes valid TCP packets, traditional intrusion detection systems often ignore it51. This is mitigated by implementing strict ReadHeaderTimeout and WriteTimeout limits within the async networking layer, alongside a hard concurrency cap per lane35. Furthermore, adversaries may attempt bandwidth starvation by requesting massive overlapping byte ranges to force the server to read the entire file from disk multiple times24. The strict HTTP profile mitigates this by denying multipart/byteranges requests entirely23.

Malicious Metadata and Artifacts

An attacker may attempt application-layer Path Traversal by sending URIs containing /../../etc/passwd or utilizing URL-encoded bypass techniques such as %2e%2e%2f29. The mitigation strategy requires the router to deny any requests containing .. sequences or URL-encoded equivalents prior to any path resolution algorithms26. Additionally, an adversary with local file system access might plant a malicious symbolic link (symlink) within the model directory pointing to sensitive system files. The application defends against symlink and reparse-point evasion by utilizing fs::canonicalize() to resolve the absolute path and verifying that it strictly descends from the intended base\_dir30.

Compromised Observers

If the centralized observer's private signing key is compromised via an infrastructure breach, an attacker can issue mathematically valid proofs for offline, nonexistent, or malicious IPs. The mitigation strategy limits the blast radius through aggressive key rotation policies, highly constrained expiry TTLs on receipts (e.g., 15 minutes), and the rapid distribution of Certificate Revocation Lists (CRLs). The eventual transition to a multi-observer quorum model mathematically eliminates this single point of failure.

Local Unprivileged Users

A local malware script or unprivileged user process may attempt port hijacking by binding to the exact same port as a restarting lane, abusing the SO\_REUSEADDR flag to steal inbound P2P traffic. On Windows platforms, utilizing the SO\_EXCLUSIVEADDRUSE socket option explicitly prevents forcible rebinding by malicious software12. On Unix platforms, strict binding to specific interfaces rather than wildcard addresses, combined with kernel-level unprivileged port restrictions, mitigates hijacking vectors.

9. Verification Plan

Rigorous automated testing is critical because the fleet operates in highly untrusted environments. Continuous Integration (CI) and Continuous Deployment (CD) pipelines must simulate real-world physics without exposing the build runners to the public internet or polluting the live catalog. CI pipelines must explicitly mock the observer network and the catalog ingest endpoints.

1. Unit and Deterministic Fixture Tests: The pipeline must test the std::path::Path::components() sanitization logic against an exhaustive dictionary of known traversal payloads, including null bytes (%00), NTFS alternate data streams, and extended-length path prefixes (\\\\?\\C:\\)26. The Ed25519 ZIP-215 implementation must be validated by feeding it forged [Figure omitted from source export] signatures to ensure they trigger explicit cryptographic rejection43.
2. Integration Testing (925 MiB Artifacts): The pipeline will spawn two independent Rust processes sharing a mock 925 MiB file via mmap. Utilizing operating system metrics (e.g., /proc/\[pid\]/smaps on Linux), the test asserts that the physical memory Resident Set Size (RSS) is shared and does not double1.
3. Fault-Injection and Chaos Testing: The test suite will force a port collision during startup by pre-binding a dummy listener, verifying that the lane process fails atomically with a specific exit code. Furthermore, executing a SIGKILL (kill \-9) on Lane 1 while Lane 2 is actively serving data will verify that Lane 2's HTTP throughput remains uninterrupted.
4. Malformed HTTP Fuzzing: Utilizing fuzzing frameworks such as cargo-fuzz, the pipeline will generate thousands of malformed HTTP headers per second, specifically injecting zero-length chunks, duplicated Content-Length fields, and massive Range headers, ensuring the parser fails safely and closes the TCP connection without panicking or leaking memory19.
5. Live NAT Deployment Tests: A physically isolated lab network equipped with various legacy and modern consumer routers will execute automated PCP and NAT-PMP requests, verifying successful port mapping and the graceful fallback to manual configuration strings when UPnP IGD fails38.

10. Prioritized Recommendations and Explicit Tradeoffs

11. Questions Requiring Local Evidence

Certain operational realities cannot be determined strictly through external research and require local telemetry and validation from real-world beta deployments:

1. Page Cache Thrashing Dynamics: When 50 concurrent peers attempt to download entirely different sections of a 925 MiB model over a highly constrained 10 Mbps connection, does the operating system aggressively swap to disk, or does the implementation of posix\_fadvise(POSIX\_FADV\_DONTNEED) successfully maintain low memory pressure across prolonged transfer windows?
2. PCP/NAT-PMP Viability in the Wild: What exact percentage of target home routers actively support RFC 6887 (PCP) versus RFC 6886 (NAT-PMP) versus Legacy UPnP IGD in modern 2026 consumer deployments?
3. Carrier-Grade NAT (CGNAT) Penetration: What proportion of the user base is permanently trapped behind CGNAT architectures, rendering both manual forwarding and automated PCP ineffective? If this metric exceeds 30%, the overarching architecture may eventually be forced to re-evaluate the strict exclusion of optional relay networks.
4. Windows File Locking Semantics: Does memory-mapping the artifact on Windows using CreateFileMapping introduce strict file-locking semantics that actively prevent the operator from replacing or updating the model artifact via the local UI without initiating a full, hard shutdown of both lanes?

12. Current, Directly Linked Primary Sources with Dates

The architectural paradigms, security constraints, and network protocols defined within this report are synthesized from the following primary technical standards and operating system documentation:

Works cited

1. The Linux Programming Interface \- Memory Mappings \- DEV Community, https://dev.to/cangulmez/the-linux-programming-interface-memory-mappings-5f4h
2. Memory-Mapped I/O \- Linux Kernel Internals, https://kernel-internals.org/io/mmap-io/
3. How to Create Memory-Mapped Files in Rust \- OneUptime, https://oneuptime.com/blog/post/2026-01-30-how-to-create-memory-mapped-files-in-rust/view
4. mmap-io \- crates.io: Rust Package Registry, https://crates.io/crates/mmap-io
5. Is it UB to read uninitialized memory from another process via shared memory?, https://users.rust-lang.org/t/is-it-ub-to-read-uninitialized-memory-from-another-process-via-shared-memory/137810
6. How to Create IPv6 TCP Listeners in Rust \- OneUptime, https://oneuptime.com/blog/post/2026-03-20-ipv6-tcp-listeners-rust/view
7. How to Create IPv6 Sockets in Rust \- OneUptime, https://oneuptime.com/blog/post/2026-03-20-ipv6-sockets-rust/view
8. \bind\ may incorrectly create a dual-stack socket on some platforms · Issue \#130668 · rust-lang/rust \- GitHub, https://github.com/rust-lang/rust/issues/130668
9. linux \- How do SO\_REUSEADDR and SO\_REUSEPORT differ? \- Stack Overflow, https://stackoverflow.com/questions/14388706/how-do-so-reuseaddr-and-so-reuseport-differ
10. SO\_REUSEPORT/ADDR (1/2) — How different about the condition of binding — | by Yuki Nishiwaki | ukinau | Medium, https://medium.com/uckey/the-behaviour-of-so-reuseport-addr-1-2-f8a440a35af6
11. Difference Between SO\_REUSEADDR and SO\_REUSEPORT \- GeeksforGeeks, https://www.geeksforgeeks.org/linux-unix/difference-between-so\_reuseaddr-and-so\_reuseport/
12. Using SO\_REUSEADDR and SO\_EXCLUSIVEADDRUSE \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse
13. SO\_EXCLUSIVEADDRUSE socket option (Winsock2.h) \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/winsock/so-exclusiveaddruse
14. Why on Earth can I start two flask dev servers on the same port? | Branislav Jenco, https://branislavjenco.github.io/reusing-sockets/
15. sozu/doc/configure.md at main \- GitHub, https://github.com/sozu-proxy/sozu/blob/main/doc/configure.md
16. RFC 9110 \- HTTP Semantics \- Datatracker \- IETF, https://datatracker.ietf.org/doc/html/rfc9110
17. RFC 9110 \- HTTP Semantics | RFCinfo, https://rfcinfo.com/rfc-9110/
18. RFC 9110: HTTP Semantics (Modern Consolidated RFC) | zerosday, https://www.zerosday.com/post/rfc/rfc-9110-http-semantics-modern
19. HTTP Request Smuggling: From RFC to Real-World Impact \- SecQuest, https://www.secquest.co.uk/white-papers/http-request-smuggling
20. What is HTTP request smuggling? Tutorial & Examples | Web Security Academy, https://portswigger.net/web-security/request-smuggling
21. Post Mortem: HTTP Request Smuggling Vulnerability \- The Crystal Programming Language, https://crystal-lang.org/2026/05/26/http-request-smuggling-vulnerability-in-http-server/
22. HTTP Request Smuggling, what it is, how to find it and how to stop it \- DevCentral, https://community.f5.com/kb/technicalarticles/http-request-smuggling-what-it-is-how-to-find-it-and-how-to-stop-it/312537
23. HTTP Range Requests explained, https://http.dev/range-request
24. HTTP/1.1 response to multiple range \- Stack Overflow, https://stackoverflow.com/questions/18315787/http-1-1-response-to-multiple-range
25. HTTP Range Header and Partial Downloads \- SANS ISC, https://isc.sans.edu/diary/15100
26. path\_security \- Rust \- Docs.rs, https://docs.rs/path-security
27. Path in std::path \- Rust Documentation, https://doc.rust-lang.org/std/path/struct.Path.html
28. Path Traversal | OWASP Foundation, https://owasp.org/www-community/attacks/Path\_Traversal
29. What is path traversal, and how to prevent it? | Web Security Academy \- PortSwigger, https://portswigger.net/web-security/file-path-traversal
30. redasgard/path-security: Comprehensive path validation and sanitization library with 85%+ attack vector coverage \- GitHub, https://github.com/redasgard/path-security
31. Rust Path Traversal Guide: Example and Prevention \- StackHawk, https://www.stackhawk.com/blog/rust-path-traversal-guide-example-and-prevention/
32. posix\_fadvise(2) \- Linux manual page \- man7.org, https://man7.org/linux/man-pages/man2/posix\_fadvise.2.html
33. POSIX\_FADV\_VOLATILE \[LWN.net\], https://lwn.net/Articles/468896/
34. Kubernetes OOMKill due to Page Cache: Is there a solution? \- Server Fault, https://serverfault.com/questions/1190253/kubernetes-oomkill-due-to-page-cache-is-there-a-solution
35. MU Online in Rust: Hardening the Foundation, runtime, Timeouts, and Packet Size Limits, https://douglasmakey.medium.com/mu-online-in-rust-hardening-the-foundation-runtime-timeouts-and-packet-size-limits-d89a4e5b48d7
36. RFC 6886 \- NAT Port Mapping Protocol (NAT-PMP) \- Datatracker, https://datatracker.ietf.org/doc/html/rfc6886
37. RFC 6887: Port Control Protocol (PCP), https://www.rfc-editor.org/info/rfc6887/
38. Port Control Protocol \- Wikipedia, https://en.wikipedia.org/wiki/Port\_Control\_Protocol
39. NAT Port Mapping Protocol \- Wikipedia, https://en.wikipedia.org/wiki/NAT\_Port\_Mapping\_Protocol
40. URL Standard \- WhatWG, https://url.spec.whatwg.org/
41. URL Normalization \- Crawler \- Audisto, https://audisto.com/help/crawler/settings/url-normalization/
42. RFC 8032 \- Edwards-Curve Digital Signature Algorithm (EdDSA) \- Datatracker \- IETF, https://datatracker.ietf.org/doc/html/rfc8032
43. Signature forgery in Ed25519 due to missing S \< L check \- GitHub, https://github.com/digitalbazaar/forge/security/advisories/GHSA-q67f-28xg-22rw
44. Malleable signatures | Ed25519 Quirks \- Alex Ostrovski's blog, https://slowli.github.io/ed25519-quirks/malleability/
45. Ed25519 Signature Malleability in Dropbear Due to Missing S Range Check \#406 \- GitHub, https://github.com/mkj/dropbear/issues/406
46. ed25519-consensus \- crates.io: Rust Package Registry, https://crates.io/crates/ed25519-consensus
47. ed25519\_consensus \- Rust \- Docs.rs, https://docs.rs/ed25519-consensus/
48. Zcash-flavored Ed25519 for use in Zebra. \- GitHub, https://github.com/zcashfoundation/ed25519-zebra
49. ADR 0009: Ed25519 Signature Verification Semantics | Oasis Documentation, https://docs.oasis.io/adrs/0009-ed25519-semantics/
50. Verifying signatures using ZIP215 criteria · Issue \#664 · dalek-cryptography/curve25519-dalek \- GitHub, https://github.com/dalek-cryptography/curve25519-dalek/issues/664
51. What is a Slowloris Attack? \- NetScout Systems, https://www.netscout.com/what-is-ddos/slowloris-attacks
52. Slowloris DDoS Attack \- Cloudflare, https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/
53. Add HTTP server timeouts to prevent slowloris-style DoS · Issue \#2277 \- GitHub, https://github.com/kubescape/kubescape/issues/2277
54. Page Cache \- Linux Kernel Internals, https://kernel-internals.org/mm/page-cache/
55. tokio\_dual\_stack \- crates.io: Rust Package Registry, https://crates.io/crates/tokio\_dual\_stack
56. tokio\_dual\_stack \- Rust \- Docs.rs, https://docs.rs/tokio\_dual\_stack/latest/tokio\_dual\_stack/