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.boucad...@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-boun...@ietf.org> *De la part de* Aitken, Paul
*Envoyé :* vendredi 20 janvier 2023 23:03
*À :* Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>;
ip...@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-boun...@ietf.org>
<mailto:opsawg-boun...@ietf.org> on behalf of Joe Clarke (jclarke)
<jclarke=40cisco....@dmarc.ietf.org>
<mailto:jclarke=40cisco....@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
ip...@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
ip...@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
