Summary
- RFC 3360 documented firewalls and load balancers that answered an ECN-setup SYN with TCP RST simply because ECE and CWR occupied formerly reserved header bits.
- A successful retry without those flags restores a reduced connection, but does not prove who generated the first reset, whether the peer supported ECN, or whether the intolerant device was repaired.
The client sent a SYN carrying ECE and CWR. A reset came back immediately. The application reported that the server had refused the connection.
Except the server may never have seen the packet.
That is the evidentiary problem inside RFC 3360. Published in August 2002 as Best Current Practice 60, Inappropriate TCP Resets Considered Harmful addressed firewalls and load balancers that rejected TCP SYN packets using bits from the header's formerly Reserved field. ECN had assigned two of those bits. Some intermediaries treated their use as an error and emitted RST on behalf of a transport endpoint whose state they did not own.
RFC 3360 is not a present-day census. Its figures describe historical measurements, and it does not identify today's operators or products. Its durable contribution is narrower and more consequential: a control signal loses value when a middlebox uses it to express a different decision.
RST is not a generic refusal envelope
TCP reset exists to resolve bounded connection-state conditions. RFC 793 described RST for situations such as a segment that apparently does not belong to a current connection or a request reaching a nonexistent connection. The receiving TCP aborts and tells the application. RFC 9293 later consolidated TCP's state machine and retained explicit rules for generating and validating resets.
Those semantics matter because software acts on them. A reset is faster and more final than silence. It does not normally mean “an intermediary encountered an unfamiliar extension”, “a queue is full”, or “local policy dislikes one packet shape”. RFC 3360 objected to all-purpose use of RST precisely because each new meaning forces receivers to guess which decision occurred.
The distinction is not that firewalls have no authority. RFC 2979 recognized that a site may block access it regards as illegitimate, even when the traffic is standards-compliant. The boundary is whether the control remains legible. A local policy decision should not impersonate evidence that the remote TCP endpoint rejected a connection.
RFC 3360 also excluded a different case: a firewall can reset an attempt to a blocked port in a way consistent with the absence of an available connection. Its target was a box that passed ordinary TCP traffic but reset a standards-defined packet within the protocol solely because it used an extension value.
ECN made the hidden actor visible
RFC 3168's TCP negotiation for Explicit Congestion Notification used ECE and CWR, two flags allocated from the former Reserved field. An ECN-capable initiator sent both on the SYN. A capable peer could answer with ECE set and CWR clear; an ordinary peer that did not support ECN was expected to ignore the unfamiliar flags and return a normal SYN-ACK.
That graceful path depended on every participant tolerating the new values. Some deployed firewalls and load balancers did not. RFC 3360 reports that in March 2002, 203 of 12,364 tested web sites reset an ECN-setup SYN and 420 dropped it. These are the RFC's historical measurements, not a current failure rate. They show how a device that was not one of the negotiating endpoints could decide whether the endpoints were allowed to discover each other's capability.
A packet trace at the client could preserve the SYN and RST, yet still fail to identify the speaker. Source address, ports, acknowledgment and timing can make a reset plausible; they are not cryptographic provenance. Without observations around the controlled intermediaries, configuration evidence, or a repeatable path experiment, “the server rejected ECN” goes beyond the record.
The workaround restores reachability by spending semantics
RFC 3168 and RFC 3360 describe an optional compatibility move. If an ECN-setup SYN receives RST, the initiator may send another SYN with ECE and CWR cleared. If that succeeds, TCP can connect without ECN. If the plain SYN receives another reset, the initiator should abort normally.
This procedure makes the first reset provisional in one specific branch. It preserves user reachability but creates three unresolved facts.
First, the first reset might have been valid. Retrying means the receiver intentionally declines to honor it until a second, reduced attempt supplies more evidence. Second, success of the plain SYN does not prove the peer lacked ECN; a middlebox may have suppressed the negotiation. Third, failure of the first SYN may have been ordinary packet loss. A retry without ECN after timeout can disable the feature even on a tolerant path.
The RFC records why some implementers resisted fallback: it could ignore a valid first reset, turn loss into feature disablement, add six seconds or more before connection, and normalize the broken equipment instead of forcing repair. Compatibility therefore has an owner and a cost. “Users can connect” is one metric. “The extension path remains deployable” is another.
TCP Fast Open later met a related pattern. RFC 7413 notes that unknown TCP options or SYN data could be dropped, so the protocol falls back to an ordinary handshake. Again, fallback protects the transaction while concealing the lost capability. Availability dashboards that count only final success will systematically under-report extension intolerance.
Reset validation solves a different problem
RFC 5961 made blind reset attacks harder. For established connections, an in-window RST whose sequence number is not exactly the next expected value triggers a challenge ACK rather than immediate teardown. A legitimate peer can then confirm closure with another reset derived from the acknowledgment.
That mechanism strengthens acceptance evidence for a reset in synchronized state. It does not reveal why a reset acknowledging an initial SYN was generated, nor does it prove that the endpoint rather than a path device generated it. RFC 5961 itself documents middlebox corner cases: a stateful box may retransmit stale resets, produce an ACK/RST loop, or discard the challenge ACK after deleting its own flow state.
Sequence validity and semantic authority are separate. A middlebox can construct a syntactically acceptable packet while still speaking for a decision outside the meaning the endpoint assigns to it.
The private rule becomes protocol law
RFC 3360 warned that equipment rejecting valid use of reserved bits could freeze TCP evolution. Standards status did not help if the packet never reached an endpoint. Once enough paths failed, protocol implementers had an incentive to avoid the extension, deploy a fallback, or move innovation elsewhere.
RFC 6709 and RFC 9170 later generalized the mechanism. An extension point is not preserved by documentation alone. It survives through correct handling, regular variation and visible feedback. Fields that stay constant invite implementations to treat the observed subset as the whole protocol. An intolerant rule becomes harder to remove after operators depend on it and vendors stop seeing failures.
RFC 8701's GREASE method deliberately sends reserved values in TLS negotiation so intolerance appears while it is still repairable. It is a useful comparison, not proof that greasing works for every TCP field. The broader principle is that extension capacity must be exercised and its failures must remain observable.
This is where RFC 3360 meets the operating doctrine in Heng Lu's notes. Minimum common specification should leave later decisions local, and adoption should remain voluntary. A firewall operator may choose not to permit a capability. But when that choice becomes an indistinguishable endpoint reset, a local decision silently governs two endpoints and every application above them. The intermediary has acquired de facto veto power without publishing a mandate.
A receipt chain for one failed SYN
A defensible investigation starts with the exact original packet: flags, options, addresses, timestamp and intended extension. It records observation points before and after each controlled middlebox. It validates the returned RST's fields while refusing to equate plausibility with identity.
Next comes policy evidence. If an intermediary intentionally blocked the packet, the record should identify the rule, owner, software and policy versions, approved purpose, creation date and retirement condition. If no intentional policy exists, the event belongs to implementation repair rather than application blame.
The fallback branch needs its own receipt. Was a plain SYN sent because of RST, timeout or an operator test? Did it traverse the same address, route and intermediaries? Did the peer answer, and was ECN actually negotiated on a later controlled attempt? Connection establishment, extension negotiation, data exchange and application outcome are four different observations.
Finally, the repair must be tested with the extension-bearing packet. Deleting a rule or upgrading an appliance is not the result. The result is that the ECN-setup SYN reaches the intended peer, the peer's response matches its capability, the connection carries data under the agreed mode, and an independent application probe observes the expected service. Alternate paths must be checked because a successful path can coexist with an intolerant one.
What this record cannot say
The source packet does not prove that every reset to an ECN-setup SYN is inappropriate, forged or generated by a middlebox. It does not require a security device to pass every unknown flag. It does not establish current deployment rates, named vendor behavior or a present incident.
A successful ordinary handshake does not prove ECN support. An ECN-capable handshake does not prove a router marked congestion, the receiver fed it back, the sender reduced its window or the application benefited. Each is a later receipt.
The narrow conclusion is enough: RST has operational force because endpoints believe it represents transport state. Reusing it for unfamiliarity makes that force cheaper to exercise and harder to attribute.
Sources
- https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3360.xml
- https://datatracker.ietf.org/api/v1/doc/document/rfc3360/?format=json
- https://datatracker.ietf.org/doc/rfc3360/
- https://datatracker.ietf.org/doc/rfc3360/history/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://www.rfc-editor.org/errata_search.php?rfc=3360
- https://www.rfc-editor.org/info/rfc3360
- https://www.rfc-editor.org/rfc/rfc793.html
- https://www.rfc-editor.org/rfc/rfc1122.html
- https://www.rfc-editor.org/rfc/rfc1812.html
- https://www.rfc-editor.org/rfc/rfc2026.html
- https://www.rfc-editor.org/rfc/rfc2873.html
- https://www.rfc-editor.org/rfc/rfc2979.html
- https://www.rfc-editor.org/rfc/rfc3168.html
- https://www.rfc-editor.org/rfc/rfc3360.html
- https://www.rfc-editor.org/rfc/rfc3360.txt
- https://www.rfc-editor.org/rfc/rfc5961.html
- https://www.rfc-editor.org/rfc/rfc6709.html
- https://www.rfc-editor.org/rfc/rfc7413.html
- https://www.rfc-editor.org/rfc/rfc8311.html
- https://www.rfc-editor.org/rfc/rfc8540.html
- https://www.rfc-editor.org/rfc/rfc8701.html
- https://www.rfc-editor.org/rfc/rfc9170.html
- https://www.rfc-editor.org/rfc/rfc9293.html
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
