Re: [IPFIX] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

[Benoit Claise <[e-mail]>]

Hi Andrew,

On 9/27/2023 2:30 PM, Andrew Feren wrote:
>
> Hi Paul,
>
> I’m coming in a little late on this, but I took a few days to scan the 
> many thousands of pcaps I’ve collected from customers over the last 20 
> years and look at existing exporter and collector implementations that 
> I have access too.  Based on what I have found there may be no 
> complaints because no one has implemented it.  I was unable to find a 
> single use of either ipv4Options(208) or tcpOptions(209) in the wild.  
> Looking at the RFCs and errata it is hard to see how anyone could have 
> implemented these IEs without many questions.
>
Many thanks for the investigation. This is very useful.
>
> I asked myself how I would have implemented this if I had to make a 
> decision based on what exists and came to the same conclusions you did 
> in 
> https://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/. 
> If others reach the same conclusions my inclination is to make a 3^rd 
> and, hopefully final, errata attempt.  As a collector developer I’m 
> sympathetic to the option to deprecate these IEs and try again, but I 
> feel like a careful errata may be OK in this case.
>
Exactly my thoughts.

Regards, Benoit
>
> -Andrew
>
> *From: *IPFIX <[e-mail]> on behalf of Aitken, Paul 
> <paitken=[e-mail]>
> *Date: *Thursday, September 21, 2023 at 4:55 PM
> *To: *[e-mail] <[e-mail]>, 
> opsawg <[e-mail]>, Benoit Claise <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [IPFIX] draft-ietf-opsawg-ipfix-fixes: 
> tcpOptions/ipv4Options bit mappings
>
> [EXTERNAL] CAUTION: This email originated from outside of the 
> organization. Do not click links or open attachments unless you 
> recognize the sender and know the content is safe.
>
> Med, no-one else has reported problems with these elements in the last 
> 15 years. So what do you want to achieve?
>
> We should not update the registry without first understanding what has 
> already been implemented. The best we can hope for is that existing 
> implementations show consensus on the encoding. If so, then we should 
> ensure that the IPFIX registry and errata align with the implementations.
>
> If there's no consensus then it would be better to create new elements 
> and deprecate the existing ones. But it's not worth creating new 
> elements unless they would be broadly deployed.
>
> P.
>
> On 20/09/2023 15:12, [e-mail] wrote:
>
>     Hi Paul, all,
>
>     I digged into ipfix archives to see the discussion that happened
>     around these errata and when scrolling I found this message:
>
>     https://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/
>     [mailarchive.ietf.org]
>     <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/__;!!OSsGDw!M5ZqkW9HRmWiKi1m5ic3WY8jsxZ45KQaLkjwDuXEsMATOM758Px86B3PFsAdY1QMsKrL16GYBWpn0jnJUvJb6MlP$>
>     but no follow-up.
>
>     This confirms my initial assessment that a fix is needed.
>
>     Cheers,
>
>     Med
>
>     *De :*BOUCADAIR Mohamed INNOV/NET
>     *Envoyé :* mardi 19 septembre 2023 15:02
>     *À :* 'Aitken, Paul' <[e-mail]>
>     <mailto:[e-mail]>; opsawg <[e-mail]>
>     <mailto:[e-mail]>; Benoit Claise <[e-mail]>
>     <mailto:[e-mail]>
>     *Objet :* RE: draft-ietf-opsawg-ipfix-fixes:
>     tcpOptions/ipv4Options bit mappings
>
>     Hi Paul,
>
>     Yes, that’s what I was referring to in my previous messages when I
>     said “FWIW, (1) is what was followed in RFC5102 but changed since
>     then by errata.”.
>
>     I’m having trouble with that errata as I don’t understand why the
>     reversal was only made at the octet level and not the full IE +
>     how to link that with “Option number X is mapped to bit X”.
>
>     Thank you.
>
>     Cheers,
>
>     Med
>
>     *De :*Aitken, Paul <[e-mail]>
>     *Envoyé :* mardi 19 septembre 2023 12:13
>     *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>     opsawg <[e-mail]>; Benoit Claise <[e-mail]>
>     *Objet :* Re: draft-ietf-opsawg-ipfix-fixes:
>     tcpOptions/ipv4Options bit mappings
>
>     Med, this figure originally appeared in section 5.8.8 of
>     draft-ietf-ipfix-info-13, -14, and RFC 5102 with the bits in this
>     order:
>
>                    0     1     2     3     4     5     6     7
>
>                +-----+-----+-----+-----+-----+-----+-----+-----+
>
>                |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
>
>                +-----+-----+-----+-----+-----+-----+-----+-----+
>
>
>     The bits were reversed by this errata:
>     https://www.rfc-editor.org/errata/eid2946 [rfc-editor.org]
>     <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid2946__;!!OSsGDw!M5ZqkW9HRmWiKi1m5ic3WY8jsxZ45KQaLkjwDuXEsMATOM758Px86B3PFsAdY1QMsKrL16GYBWpn0jnJUlDjvWkS$>
>
>     Also see https://www.rfc-editor.org/errata/eid1739
>     [rfc-editor.org]
>     <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid1739__;!!OSsGDw!M5ZqkW9HRmWiKi1m5ic3WY8jsxZ45KQaLkjwDuXEsMATOM758Px86B3PFsAdY1QMsKrL16GYBWpn0jnJUqK4eb1D$>
>
>     P.
>
>     On 19/09/2023 09:49, [e-mail] wrote:
>
>         Hi all,
>
>         The description of these IEs says that “Options are mapped to
>         bits according to their option numbers. Option number X is
>         mapped to bit X”, however the drawing does not reflect that
>         (tcpOptions):
>
>         0     1     2     3     4     5     6     7
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         |   7 |   6 |   5 |   4 |   3 |   2 |   1 | 0 |  ...
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         8     9    10    11    12    13    14    15
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         ... |  15 |  14 |  13 |  12 |  11 |  10 |   9 | 8 |...
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         16    17    18    19    20    21    22    23
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         ... |  23 |  22 |  21 |  20 |  19 |  18 |  17 | 16 |...
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         . . .
>
>         56    57    58    59    60    61    62    63
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         ... |  63 |  62 |  61 |  60 |  59 |  58 |  57 | 56 |
>
>         +-----+-----+-----+-----+-----+-----+-----+-----+
>
>         I suspect that the confusion is rooted in the interpretation
>         of “bit X”: as (1) “bit position X” or the resulting (2)
>         “binary value”:
>
>          1. If (1) is followed, then bit#0 would be mapped to option
>             0, bit#1 to option 1, and so on. This logic is followed,
>             e.g., for ipv6ExtensionHeaders.
>          2. If (2) is followed, then bit#63 would be mapped to option
>             0, bit#62 to option 1, and so on.
>
>         In both cases, the drawing is not aligned with the narrative
>         text. We may either consider updating the drawing or the text.
>
>         Which change is likely to have less impact on existing
>         implementations? FWIW, (1) is what was followed in RFC5102 but
>         changed since then by errata.
>
>         Thank you.
>
>         Cheers,
>
>         Med
>
>         ____________________________________________________________________________________________________________
>
>         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.
>
>     ____________________________________________________________________________________________________________
>
>     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.
>
> This email message and any attachments are confidential. If you are 
> not the intended recipient, please immediately reply to the sender and 
> delete the message from your email system. Thank you.