Re: [IPFIX] FW: CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

Hi Paul,

Thanks for engaging.

On top of what Med mentioned... When you mention "non-interoperable 
IPFIX devices", I would like to understand which interoperability risk 
do we speak about
1. the IPFIX protocol. Not really
2. the Exporter. It should export what it observes.
3. the Collector. You mean the correlation of tcpControlBits IPFIX IE 
coming from different Exporters with different TCP capabilities, right?
Unless you know the TCP capabilities of each Exporter, you won't know.
Is IPFIX the right protocol to solve that interop issues, by using 
different IPFIX IEs for different capabilities for each new bit 
allocaiton? I tend to believe it's not. See point 2 above. IIRC, you 
tend to believe it's not:

    "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."

Regards, Benoit

On 1/23/2023 8:16 AM, mohamed.boucadair@orange.com wrote:
>
> 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: 
> https://mailarchive.ietf.org/arch/msg/tcpm/RK1ixEOA6HaP7TGmtNLXGI2RBdM/.
>
> Cheers,
>
> Med
>
> *De :*OPSAWG <opsawg-bounces@ietf.org> *De la part de* Aitken, Paul
> *Envoyé :* vendredi 20 janvier 2023 23:03
> *À :* Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; 
> ipfix@ietf.org; opsawg <opsawg@ietf.org>
> *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.
>
> P.
>
>
>
> 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.
>
>     Joe
>
>     *From: *OPSAWG <opsawg-bounces@ietf.org>
>     <mailto:opsawg-bounces@ietf.org> on behalf of Joe Clarke (jclarke)
>     <jclarke=40cisco.com@dmarc.ietf.org>
>     <mailto:jclarke=40cisco.com@dmarc.ietf.org>
>     *Date: *Tuesday, January 17, 2023 at 11:24
>     *To: *opsawg@ietf.org <opsawg@ietf.org> <mailto:opsawg@ietf.org>
>     *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
>     athttps://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html
>     [boucadair.github.io]
>     <https://urldefense.com/v3/__https:/boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html__;!!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.
>
>     Thanks.
>
>     Joe
>
>
>
>     _______________________________________________
>
>     IPFIX mailing list
>
>     IPFIX@ietf.org
>
>     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$  <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipfix__;!!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.
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix