System UDP reply writer copies client ECN into reconstructed replies

Summary

The system UDP reply writer copies the initiating client packet's ECN field into reconstructed server-to-client packets. ECN describes a packet in its own direction; a client packet's ECN marking is not a valid source for a reply's ECN field.

The writer saves the initiating IP header and reuses it when constructing replies, without resetting its ECN field.

Affected version

• sing-tun v0.9.0-beta.4, commit f4c1f3ae265b930460774295b8fe5c73596c81cf.
• Dependency of sing-box 1.14.0, revision 0b8995879f29a9b98ee027bc17b75e101445b238.
• Affected code path: system IPv4 UDP reply writer.

I have not tested the current development branch.

Expected behavior

The reply writer must not obtain reply ECN from the saved client header. If the outbound path supplies no reply ECN metadata and does not implement ECN propagation, reconstruct replies as Not-ECT rather than copying the opposite direction's marking.

ECT(0)/ECT(1) indicate ECN capability for the packet carrying those bits. CE indicates congestion experienced by that packet. None of these values can be inferred for a server-to-client reply from the initiating client-to-server packet. See RFC 3168, section 5.

Actual behavior

Saved client IPv4 header: ECN = ECT(0)
Reply input: UDP payload, no reply ECN metadata
Reconstructed IPv4 reply: ECN = ECT(0), copied from the client header

The reply inherits the saved client header's ECN instead of reflecting the absence of ECN metadata on the reply path.

Source path

At commit f4c1f3ae265b930460774295b8fe5c73596c81cf:

1. preparePacketConnection saves the initiating IP/UDP header:

   copy(headerCopy, packet[:headerLen])
   

2. The IPv4 reply writer retains that header for the UDP connection.

3. systemUDPPacketWriter4.preparePacket prepends it to each reply payload:

   copy(buffer.ExtendHeader(len(w.header)), w.header)
   

4. The writer updates addresses, ports, lengths and checksums, but does not reset the IPv4 ECN bits. Single-packet and batch reply paths use this preparation method.

For comparison, the mixed/gVisor UDP writer passes TOS: 0 when constructing its reply.

Proposed local regression test

This is a test outline, not an implemented or executed reproducer:

1. Construct a valid IPv4/UDP client packet with ECN ECT(0).
2. Use its header to initialize the system UDP reply writer through the same preparation path used for a new UDP NAT entry.
3. Supply an arbitrary reply payload without reply ECN metadata.
4. Generate the reply using preparePacket and inspect the reconstructed IPv4 header.
5. Assert that the reply has ECN Not-ECT. The current header-copy implementation is expected to retain ECT(0), causing the assertion to fail.

Cover the shared preparation method and its single/batch callers. Include Not-ECT, ECT(0), ECT(1), and CE as input cases. These are proposed test cases, not results from an executed test suite.

Scope and requested fix

Please stop inheriting ECN from the client header when constructing system UDP replies. For a payload-only reply interface without ECN support, clear the ECN bits before calculating the IPv4 header checksum. Define DSCP handling separately rather than changing the entire TOS byte as an incidental part of this fix.

This report focuses on the IPv4 writer. The IPv6 saved-header writer deserves a separate traffic-class review. I have not implemented the regression test or validated a patch.

AI assistance disclosure

I used OpenAI GPT-6 Astra to help identify and diagnose this issue while investigating connection problems in an iOS app.

Start in stack_system.go with preparePacketConnection and systemUDPPacketWriter4.preparePacket, then trace the shared single- and batch-reply callers. Review the proposed IPv4 regression cases for Not-ECT, ECT(0), ECT(1), and CE inputs. Done means replies without ECN metadata are reconstructed as Not-ECT while DSCP handling remains separate and checksums are valid.