Re: [IPFIX] FW: CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element Mon, 23 January 2023 07:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEF54C14CEFC; Sun, 22 Jan 2023 23:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.985
X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JAjfvMPhhBPA; Sun, 22 Jan 2023 23:16:36 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 5A2A1C14F738; Sun, 22 Jan 2023 23:16:36 -0800 (PST)
Received: from (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4P0hH606Fyzyps; Mon, 23 Jan 2023 08:16:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1674458194; bh=9T8qKQN02CIH+guaSpKCXJm9W3y9gAaWqetSp9PfaFA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=RXkXBKZIzfub15qSg7LjGDVdTJorG27V4kY/p8hXVNI/XwDFPb3+fBSeN4F8FriWR pqTfyzaJrLHEk5sy+JcilJwa9daAWv5yKXWefmmn6JgkO94GCzJtiPuH2WrEN3DmF+ 8P+u/pYag/FdjSzwRQnHxIKthrcBSGlyFEuOd4Z1QJk/u7+IXNriYdNfRyjQHKkJYv YmnBqCv6PAk/RwkOFO9UlaS5bv8OaHgqB3wCwi9en2PJ1P3TInHv7lakxl8wfQyMvF Q7m61lU0ABwu0NdPok+VUEvNz7/RmoXE2SLVksmArGPqFRtgldK18Y5MXh9eNca+2J jroJq04EUpi9Q==
To: "Aitken, Paul" <>, "Joe Clarke (jclarke)" <>, "" <>, opsawg <>
Thread-Topic: [IPFIX] FW: CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Thread-Index: AQHZKo+H0TSozYiXhk6nNn2fVr0Fyq6l9+nsgAHoz4CAA7f4IA==
Date: Mon, 23 Jan 2023 07:16:33 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2023-01-23T06:50:12Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=38cbd374-c6c4-42ea-b43a-74753ed85fb0; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_b9185d07c7894481a4194820c4e57ce4orangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [IPFIX] FW: CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Jan 2023 07:16:40 -0000

Hi Paul, all,

Thank you for sharing your thoughts.

If we follow the reasoning below, the IETF should never publish RFC7125 to fix the misalignment issue that was in RFC5102! It is unfortunate that the fix in 7125 is broken (which is fair because there was no complete (*) TCP flag registry at that time).

RFC7125 is broken not only because it reflects a stale interpretation of the flags and also because it leaves the room for an exporter to decide to not export some flags as observed, which is suboptimal (e.g., DDoS detection/mitigation).

The proposal does not require an exporter to associate a meaning with the flags. So, no implementation change will be needed in the future when a new flag is associated with a meaning or deprecated. The behavior of the exporter is thus simplified and will always reflect what was observed.

(*): There was actually the registry create by rfc3540, but that registry is incomplete. We fixed that in TCPM as you can see here:


De : OPSAWG <> De la part de Aitken, Paul
Envoyé : vendredi 20 janvier 2023 23:03
À : Joe Clarke (jclarke) <>;; opsawg <>
Objet : Re: [OPSAWG] [IPFIX] FW: CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

As a co-author of many of the IPFIX RFCs, expert reviewer for IANA, and author of IPFIX code, I disagree with the premise that the current tcpControlBits definition is problematic for interoperability because some values have since been deprecated.

Rather, the interoperability risk is in making non backwards compatible changes to the existing definition.

Since IANA has changed bit 7 from Nonce Sum to "Reserved for future use" rather than deprecating it, a time will come when it's allocated for a future purpose. This will guarantee non-interoperability since new IPFIX devices will export the bit with a different meaning than existing / old devices.

There may be many devices in the field which cannot be found or updated which will continue to export the existing tcpControlBits definition. It's impossible to guarantee that all such devices have been updated or removed. And all existing IPFIX code libraries must be updated.

If we want to put IPFIX's tcpControlBits under IANA's control with an IPFIX Information Element which follows IANA's TCP Header Flags specification, then a new Information Element should be allocated. However this seems dangerous since the same could happen again: an in-use bit could be marked as "Reserved" then re-allocated for a different purpose, and we'd have non-interoperable IPFIX devices.

TLDR: this document should not be adopted.


On 19/01/2023 16:53, Joe Clarke (jclarke) wrote:
Forwarding to ipfix@ for more eyes on this.  Please reply to opsawg@ with any comments or questions.


From: OPSAWG <><> on behalf of Joe Clarke (jclarke) <><>
Date: Tuesday, January 17, 2023 at 11:24
To:<> <><>
Subject: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Happy new year, all.  One of the AIs that slipped through the cracks coming out of 115 was a call for adoption for draft-boucadair-opsawg-rfc7125-update.   One of the asks of Med at 115 was to look at what else might need to be done from an IE registry standpoint.  He replied on-list to that a while ago:

“Yes, I had a discussion with Benoît during the IETF meeting to see how to handle this. We agreed to proceed with at least two documents:

1.       draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX RFC.

2.       Edit a second draft to “clean” other entries in registry. This document is intended to include only simple fixes and which do not require updating existing RFCs. The candidate list of these proposed fixes can be seen at []<;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI6J3rDFp$>. New IEs, if needed, will be moved to a separate document. simple-ipfix-fixes may or may not be published as an RFC.”

So, let this serve as a two-week call for adoption for the existing draft-boucadair-opsawg-rfc7125-update document.  Please reply on-list with your comments, support, or dissent by January 31, 2023.




IPFIX mailing list<>;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$<;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$> [ietf[.]org]


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.