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".
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 }.
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.
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.
P.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
