Allow server probing packets on known 4-tuples

[flub]

In RFC9000 the client can probe new network paths. However once the client has probed such a path the server also knows about the new network path and can start probing it as well.

Currently the client discards such off-path probing packets from the server. Instead it should keep track of the 4-tuples the server is aware off and accept probing packets from them.

[poka-IT]

We hit a closely-related variant of this issue in production (Warren, a peer-to-peer VPN over QUIC), with two extra observations that may be worth folding into the scope of this issue (or splitting into a follow-up: happy either way).

Symmetric case: server drops client's off-path probing packets

early_discard_packet (noq-proto/src/connection/mod.rs:2287-2320) drops on either side when the incoming packet's network_path.remote differs from the active path and remote_may_migrate() is false. The issue description focuses on the client → server direction, but the same drop fires server-side when:

• the server is configured with ServerConfig::migration(false) (RFC 9000 standard "stable server IP" deployment), and
• the client has multipath + n0_nat_traversal enabled (default for iroh-based stacks).

In that config, the client legitimately emits off-path PATH_CHALLENGE frames via Connection::send_nat_traversal_path_challenge (mod.rs:2070-2120). The server receives them on 4-tuples it has never seen, early_discard_packet returns true before the payload is decrypted, the probe never reaches the Frame::PathChallenge arm in process_payload (mod.rs:4956-4979), and from there things spiral: noq eventually logs failed closing path err=LastOpenPath, Connection::read_datagram stops delivering anything to the application, and the pump on the server side stalls until max_idle_timeout (default 30 s) fires.

So #607 as stated ("client should accept server probes on known 4-tuples") and our observation ("server should accept client probes on 4-tuples the client has advertised / on the remote IP it has already validated") are the two faces of the same bug: early_discard_packet runs before decryption and therefore cannot tell a migration attempt apart from a probing packet, so it conservatively drops both whenever migration is forbidden.

Repro (no Warren stack needed)

Minimal repro inside the noq workspace (we have a longer Hetzner-paired bench, but a tokio::test reproduces it as well):

1. Server: Endpoint::server(..) with ServerConfig::migration(false), multipath + n0_nat_traversal left at iroh defaults (max_concurrent_multipath_paths = 13, max_remote_nat_traversal_addresses = 12).
2. Client: Endpoint::client(..) with the same defaults, connects to the server.
3. Once the handshake completes, the client's n0_nat_traversal state machine starts emitting off-path PATH_CHALLENGE to alternate candidates (any non-loopback NIC, IPv6, etc.). For us this is what previously forced us into clear_ip_transports() / with_bind_local_ip workarounds upstream of this code path.
4. Application-level recv_datagram on the server pumps zero datagrams until max_idle_timeout; logs show LastOpenPath and the discarding packet from unrecognized peer trace in early_discard_packet.

Setting ServerConfig::migration(true) masks the symptom (path is allowed to migrate, so the drop never fires). That is not viable for a VPN exit where the server IP is contractually fixed and we do not want migration semantics.

Workaround we ship in our fork (and why we are not happy with it)

Our short-term fix is a TransportConfig::disable_path_migration flag that, when set, makes early_discard_packet accept the off-path packet onto the existing path instead of dropping it: i.e. we treat every off-path arrival as "not a migration", regardless of whether it is actually a probe or not. To keep that consistent we also force-disable max_concurrent_multipath_paths and max_remote_nat_traversal_addresses whenever the flag is on, because iroh's QuicTransportConfigBuilder re-enables multipath by default and offers no public setter to turn it off, so we would otherwise get extra paths that immediately fail validation.

This works but it is coarse: we lose all path validation safety on the receive side and we have to disable multipath/QNT entirely, even though we would be fine consuming QNT for hole-punching as long as the inbound probes were recognised properly. We would prefer to drop the flag and rely on the upstream fix.

Possible directions: would value your read on the design

1. Extend tracking, then consult it in early_discard_packet: client side already keeps probe state in n0_nat_traversal::ClientState::mark_probe_sent; the symmetric server tracking would be the 4-tuples advertised via the peer's ADD_ADDRESS frames (already parsed around mod.rs:5494+). A has_expected_probe(remote) accessor on n0_nat_traversal::State, consulted before the remote_may_migrate check, would cover both directions without exposing decryption-ordering changes.
2. Defer the discard decision until after AEAD: heavier, but lets process_payload see PathChallenge / PathResponse and decide per-frame whether to migrate, probe, or drop. Closer to RFC 9000 §9.3.3 wording.
3. Status quo + opt-in flag: keep early_discard_packet strict but expose a documented accept_off_path_probes setter for stacks that knowingly want multipath/QNT-style probing. Essentially upstream-ising our workaround minus the multipath force-off.

We would happily contribute the fix once you confirm the preferred direction, and the intended scope of this issue (pure client-side per the title, or both directions). Bench data on this is from paired CCX23 Hetzner runs across two EU regions: can post the relevant numbers here on request.

[flub]

I have a number of questions about how you use iroh and noq, and also some observations. But before going there could you please create a new issue with the contents of your message? So far I don't think it is part of this and I think discussing it here will be confusing in the future, I'd like to hide it here as off-topic. If we do end up concluding it is related with this we can still mark it as duplicate and update here.

Thanks