Re: [IPFIX] [**EXTERNAL**] RE: WG LC: IPFIX documents

[[e-mail]]

Hi Paul,

Thanks for the follow-up. Much appreciated.

Please see inline.

Cheers,
Med

De : Aitken, Paul <[e-mail]>
Envoyé : mardi 23 janvier 2024 18:25
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Joe Clarke (jclarke) <[e-mail]>; [e-mail]
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

Med,


Why does the document identify issues without proposing solutions to them all? How and when will those other issues be fixed?
[Med] The new IEs in this I-D fix all the issues.

Then please don't write "some of".
[Med] We do already say “this section specifies a set of new IEs to address **all the ipv6ExtensionHeaders IE limitations **”.





 MSB                                                                 LSB

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 |  EH Type#1    |   Count       |...|  EH Type#n      |   Count       |

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Abstract Data Type:  unsigned64

This is neither a simple IE, nor an unsigned64. It's a structured data type, ie a variable-length array of { type, count } tuples.
[Med] Do we need to define a new type for this?

See subTemplateList in RFC 6313.

   Examples include a structured data type composed of multiple pairs of
   ("MPLS label stack entry position", "MPLS label stack value")

which is similar to what's proposed here: multiple pairs of { type, count }.

[Med] Please find the candidate changes at Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - draft-ietf-opsawg-ipfix-tcpo-v6eh.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt&url_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/subTemplateList/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt>.

Again, the "octetArray" type is somewhat misleading as it's really a 32tetArray.
[Med] I’m not sure this is problematic given that the definition of octetArray indicates explicitly the following:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

32-bit values are being encoded, not octets.
[Med] This is now discussed in a separate thread. Let’s try to converge there. Thanks.

    7.  Security Considerations

The ipv6ExtensionHeadersChainLength could be used to determine hardware capabilities and limitations, and possibly even to identify the hardware through which the traffic is flowing.
[Med] Not sure how this can be used to identify the hardware.

The reported values will be hardware specific, so the information could be used for hardware fingerprinting. Insufficient on its own, but potentially useful in combination with other information.

The point is that no other IEs encode specific information about hardware capabilities.

[Med] Added this note:

“ipv6ExtensionHeadersChainLength and ipv6ExtensionHeadersLimit IEs can be exploited by an unauthorized observer as a means to deduce the processing capabilities of nodes. {{Section 8 of !RFC7012}} discusses the required measures to guarantee the integrity and confidentiality of the exported information.”


P.
____________________________________________________________________________________________________________
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.