Re: Accurate ECN support in tcpdump/libpcap

["Scheffenegger, Richard via tcpdump-workers" <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com>
>
> Date: Mon, 24 Nov 2025 08:19:50 +0000
>
>
> 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 <denis () ovsienko info> 
> Sent: Samstag, 22. November 2025 16:21
> To: Michael Tuexen <michael.tuexen () lurchi franken de>
> Cc: Scheffenegger, Richard <Richard.Scheffenegger () netapp com>; tcpdump-workers () lists tcpdump org
> 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 <michael.tuexen () lurchi franken de> 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 -- tcpdump-workers () lists tcpdump org To unsubscribe send an email to 
> tcpdump-workers-leave () lists tcpdump org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s