Repository navigation
fix(network): normalize IPv4-mapped transparent TCP destinations - #5101
Conversation
|
🌿 Preview your docs: https://nvidia-preview-pr-5101.docs.buildwithfern.com/openshell |
EmilienM
left a comment
There was a problem hiding this comment.
Another iteration needed: 1 major, 3 minor (inline, 1 below)
The core fix is right and the new unit tests pass locally. The major is about verification, not the code: the new e2e probe has never executed, and the V6-family relay establishment it covers only runs on that path.
Outside the diff:
- Minor:
crates/openshell-isolation-interface/src/contract.rs:585,PendingTcpOpen.destinationis documented as the original destination the backend captured, butpreauthorize_transparent_opennow rewrites it in place; a one-line doc note (or canonicalizing at capture) keeps the contract accurate.
How this was reviewed
- Commit
dedaee7a, round 1 - Deep review, because the change routes supervisor network policy (crates/openshell-supervisor-network/src/proxy.rs), sandbox socket mediation (crates/openshell-sandbox/src/network_broker.rs), and the transparent TCP e2e (e2e/rust/tests/transparent_tcp.rs)
- Passes: architecture, performance, security, scalability, rust, then correctness
- Independent skeptics checked each candidate finding (1); 1 of 2 held up
- Repo rules read from
origin/main: AGENTS.md, CLAUDE.md, CONTRIBUTING.md - Not covered: the Docker/Podman E2E suite (CI shows
test:e2e not applied; see the major finding)
|
/ok to test 48ac0ec |
|
Label |
|
/ok to test d2a2283 |
Signed-off-by: divesh <dgude@nvidia.com>
Signed-off-by: divesh <dgude@nvidia.com>
Signed-off-by: divesh <dgude@nvidia.com>
d2a2283 to
bd0ec39
Compare
|
/ok to test bd0ec39 |
Compatibility review (advisory)New or updated breaking changes; see the full report for all findings. 1. policy — No explicit risk acceptance foundTransparent TCP destinations previously retained their mapped IPv6 identity but now become IPv4, preventing mapped
Review details
Advisory review; publication gates are unchanged. |
Summary
A transparent TCP connection allowed for an IPv4 destination was denied when a dual-stack client used its
::ffff:form. Canonicalize the destination before routing, policy DNS lookup, policy evaluation, and denial reporting, while preserving native IPv6 scope and flow information.Related Issue
Closes #5093
Changes
to_canonical().AF_INET6connection, and document equivalent IPv4 policy matching.Release Notes
Transparent TCP connections now evaluate IPv4-mapped IPv6 destinations as IPv4. If an endpoint rule uses
host: "::ffff:203.0.113.7", change it tohost: "203.0.113.7".Testing
Commands passed:
cargo test --offline -p openshell-supervisor-network --lib proxy::tests::ipv4_mappedcargo test --offline -p openshell-supervisor-network --lib -- proxy::tests::ipv4_mapped staged_ reserved_ metadata_staging --test-threads=1cargo clippy --offline -p openshell-supervisor-network --lib --tests -- -D warningscargo fmt --check -p openshell-supervisor-network -p openshell-isolation-interfacerustfmt --check --edition 2024 e2e/rust/tests/transparent_tcp.rsmise run --skip-tools docs:navThe focused Docker E2E run was canceled after stalling on base-image metadata from
ghcr.io/astral-sh/uvandnvcr.io/nvidia/base/ubuntu, before sandbox tests started. The repository-wide commit hook also failed in unrelated local Python tooling; the commit uses the completed scoped checks above.Checklist