TCP Processing of the IPv4 Precedence Field
obsoleted by
- rfc-9293 — Transmission Control Protocol (TCP)
Extracted elements (14)
IPv6 traffic class octet has no defined precedence or security parameter bits — only DSCP semantics per RFC 2474 — so there is no conflict between TCP and DiffServ on IPv6. The problem described in this memo is IPv4-specific.
The proposed modification resolves the TCP/DiffServ conflict by having TCP ignore precedence entirely, trading away a rarely-used and weakly protective security feature (precedence-based reset) to eliminate a serious DoS vulnerability and restore interoperability in DiffServ networks.
There is no field in the TCP header that indicates the precedence of a segment; instead, the precedence field in the IP packet header is used. This is why DiffServ modifications to IP header bits conflict with TCP precedence semantics.
Problem #1: In a DiffServ-capable network, intermediate nodes may modify the precedence bits of SYN and/or ACK packets during TCP synchronization. A precedence-aware TCP module will then refuse to establish the connection even when both endpoints agree on the same precedence.
Problem #2: For an established TCP connection, if an intermediate DiffServ node modifies the precedence field of a segment so that it differs from the value agreed during connection setup, RFC 793-compliant TCP will reset the connection erroneously.
Problem #3 (mirror of #1): Intermediate nodes may alter SYN and ACK precedence fields such that both endpoints believe they agreed on precedence when they actually picked different values, allowing a connection that RFC 793 would require to be rejected.
Problem #4 (mirror of #2): If one endpoint changes its precedence mid-connection, RFC 793 requires a reset, but intermediate DiffServ nodes may restore the original precedence value, suppressing the required reset and masking the mismatch.
After a TCP connection is established, each end sends segments with its desired precedence, and the other end must ignore the precedence of received packets. The connection must not be reset due to precedence differences, whether caused by the remote end or intermediate nodes.
TCP must ignore the precedence of all received segments. During synchronization, both ends must ignore the precedence fields of SYN and SYN ACK packets, and a connection must be established if all RFC 793 conditions are satisfied except precedence.
The TCP Control Block (TCB) stores connection state including precedence of the connection. RFC 793 requires both ends to agree on precedence and security parameters; any mismatch during or after synchronization requires a reset.
A TCP implementation that resets connections upon any segment with an incorrect precedence field, regardless of sequence number correctness, is vulnerable to denial-of-service attacks: an attacker who guesses port numbers needs only send two segments with different precedence values to guarantee terminating the connection.
The stricter RFC 793 precedence rules provided marginal additional security against TCP spoofing attacks, as attackers would need to guess both the initial sequence number and the precedence setting. Removing precedence enforcement eliminates this minor protection.
The DiffServ DS field reuses the IPv4 TOS octet with a new layout: bits 0-5 (DSCP, Differentiated Services Code Point, 6 bits), bits 6-7 (CU, currently unused, 2 bits). The DSCP includes the three bits formerly known as the precedence field.
The IPv4 TOS octet is structured as: bits 0-2 (PRECEDENCE, 3 bits), bits 3-6 (TOS, 4 bits), bit 7 (MBZ, Must Be Zero). The precedence field occupies the three leftmost bits.