On Thu, 13 Nov 2025 23:16:51 +0100 Michael Tuexen <[email protected]> wrote:
> > In all diagrams you can see the reserved space is a unstructured > > block rather than a bitmap pre-allocated into individual 1-bit > > flags with names such as ReservedFlag-16, ReservedFlag-15, > > ReservedFlag-14 etc. > Have a look at the IANA registry: > https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags > IANA handles them as 12 bits. Hello Michael and all. I have taken some time to study the specifications a bit better. You are right, the IANA registry currently indeed spells all 12 bits as individual flags/bits, which is consistent with Section 6 "IANA Considerations" of RFC 9293. So I was wrong thinking this was never the case. What led me to think this way is Section 3.1 "Header Format" of RFC 9293, which includes a packet diagram with a single 4-bit "Rsrvd" field rather than four single-bit flags, which does not match the prose and the IANA registry. This is now RFC erratum ID 8654. As far as I can tell, it still holds that the implementation of TCP flags in libpcap as "tcp[tcpflags]" (which is "tcp[13:1]") in 2001 was fully consistent with both RFC 3168 (published the same year), RFC 793 (published in 1981) and the expression syntax (packet data loads are 8-bit unless explicitly specified otherwise). It has been a good fit between the problem space and the solution space, and the solution has been in use for long enough to make backward compatibility a factor. As is a bit easier to see now, RFC 9293 (published in 2022) has made the old solution space a strict subset of the new problem space. This was not apparent until it became necessary to match bits 4, 5, 6 or 7 using the old syntax, as is the case with TCP-AE. As discussed, this needs a different syntax. Let me research the potential alternatives better before commenting any further on that. On a related note, even though RFC 9293 is the first document that extends TCP flags onto bits 4-7 provisionally, and draft-ietf-tcpm-accurate-ecn is the first document that allocates a TCP flag in that space, neither document seems to consider a particular security risk. If you consider the scenarios that I discussed earlier in context of libpcap syntax, it should not be difficult to see how a similar problem could occur in a completely different software/hardware TCP implementation in the course of an upgrade from 8 bits to 12 bits. -- Denis Ovsienko _______________________________________________ tcpdump-workers mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
