--- Begin Message ---
Hi Denis,
Actually, RFC3540 from 2003 (developed from early 2001 - jun 2003 adoption)
already allocated bit 7 of the 12-bit TCP flags field. That experimental draft
was declared historic in 2017 during the development process of AccECN, to
formally free up the flag bit which is part of a standards track RFC on the
verge of being adopted. Otherwise it would needed to have been bit 6 - but at
the time the exhaustion of extensibility in the TCP header was a huge
discussion factor, and having disjoint bits to convey the ACE counter later of
AccECN, would also have been sub-optimal.
(Packetdrill has code to express the 3-bits - bit 7:9 - as a octal number to
represent the ACE counter, and writing unit tests for AccECN with a faster
notation; maybe the future syntax around these header flags can also expose the
ACE counter is a similar fashion, or decode it to an octal value optionally).
So, there are prior examples, where decoding those reserved bits as part of the
tcp flags field would have been handy;
But to reiterate - I personally like the idea to be able to construct Boolean
and nested expressions, masking or or multiple bits using the same syntax. If
this means retiring tcp[tcpflags] for something more appropriate, I have no
qualms about this, however, one of the examples you constructed for the
proposed syntax was non-intuitive to me, this is what I objected against.
Richard Scheffenegger
-----Original Message-----
From: Denis Ovsienko <[email protected]>
Sent: Samstag, 22. November 2025 16:21
To: Michael Tuexen <[email protected]>
Cc: Scheffenegger, Richard <[email protected]>;
[email protected]
Subject: [tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
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://urldefense.com/v3/__https://www.iana.org/assignments/tcp-param
> eters/tcp-parameters.xhtml*tcp-header-flags__;Iw!!Nhn8V6BzJA!SvoHJ2RFc
> 0lKtdVq0okoxghwLNPO1KDZp8aw-Xfyhi7uWjpD17I0Z2rf2UsjDvyqrw0hdtToTzV0Z-w
> GVI61EBB1TOOj$
> 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
--- End Message ---
_______________________________________________
tcpdump-workers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
