F26-I2: Yes
Rationale
The selected NTCP2 ingress establishes an authenticated router-to-router session: i2pd checks RouterInfo and the handshake static key before entering the data phase. Each data frame must pass ChaCha20-Poly1305 verification before ProcessNextFrame delivers I2NP messages to the tunnel queue. Failed authentication terminates the session before onward tunnel processing. This provides the adjacency admission boundary allowed by F26.
Assessment method
Primary normative source and selected adjacency-policy analysis; no execution
Source context
i2pd 2.58.0 NTCP2 SessionConfirmed validation, AEAD receive path, I2NP queue and tunnel dispatch
Outstanding qualification
This resolves the criterion at NTCP2 ingress, not through secrecy or exclusive ownership of the 32-bit tunnel ID. The inspected tunnel lookup still does not establish an incoming-peer-to-tunnel binding; an admitted peer knowing another tunnel ID remains outside this scoped protection. No final-source allowlist, authorized-peer flood containment or upstream IP bandwidth protection is inferred. Session setup and authentication costs remain. Evidence is pinned source ordering, with no runtime exploit, full-stack or throughput test.
Public sources
- https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/NTCP2.cpp
- https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/I2NPProtocol.cpp
- https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/Tunnel.cpp
- https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/TransitTunnel.cpp
- https://i2p.net/en/docs/specs/ntcp2/
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round456.html
- round459.html
- round459-sources.json