Hi Paul,
Thanks for the follow-up. Much appreciated.
Please see inline.
Cheers,
Med
De : Aitken, Paul <pait...@ciena.com>
Envoyé : mardi 23 janvier 2024 18:25
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Joe Clarke
(jclarke) <jcla...@cisco.com>; opsawg@ietf.org
Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org
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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
