Ballot for draft-ietf-ippm-ioam-data-integrity
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
* I don't understand the construct and how it works for the POT case. Is there only a single ICV or multiple ICVs in the packet? With a single ICV you cannot reconstruct the prior ICVs for previous transit nodes as best as I can understand it. Is that correct? The draft says that nodes may update the ICV. If the ICV is updated, and the original ICV is removed, then you would want the node doing the ICV update to make a strong statement that the integrity is intact when its doing its update. That effectively makes any node that can update an ICV into a validator as well. Is that correct? * I need more explanation of how the ICVs stack in this design.
Special thanks to Ben K. for his security review. It's very thorough analysis of the application of cryptography here was especially insightful. (Even if his review may be longer than the draft itself. ;) ) * It's up to the management plain to keep the KeyID in sync across the entire domain in order for this to function correctly. Is that correct? That should be stated clearly.
# Éric Vyncke INT AD comments for draft-ietf-ippm-ioam-data-integrity-18 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Please note that Daniel Migault is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data-integrity/reviewrequest/23988/ I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Integrity vs. authentication This method basically relies on shared keys by a set a trusted nodes. I.e., it goes beyond integrity and is more about authentication (e.g., OSPFv3 *authentication* trailer per RFC 7166). Moreover, section 6.2 description is "Authentication Tag". I will trust the SEC ADs on this topic. ### Section 1 ` The method will similarly apply to future IOAM Option-Types.` this is really vague for a strong constraint on future documents. Is this statement really required ? If so, why not using BCP14 terms ? ### Section 3 The following statement requires more explanations/justitications `Since IOAM operates within IOAM-Domains, this reduces potential attack vectors and should naturally mitigate off-path threats.` ### Section 4 `The Integrity Protection header sits between an IOAM Option-Type header and its IOAM-Data-Fields` is surprising as most integrity/authentication checks are *after* the data they protect, AFAIK, this is to facilitate the job of silicon/hardware. Please add some justifications why it is not the case here. As section 5 contains `Authentication Tag MUST NOT be truncated, meaning its size MUST always be 16 octets` doesn't this mean that the Nonce must be a multiple of 4 octets ? ### Section 7.4 Similar to Gunter Van de Velde DISCUSS point, why not a MUST in `similarly, additional space required to prove integrity of the IOAM-Data-Fields SHOULD be optimal, i.e., should not exceed the MTU inside the IOAM-Domain or have adverse effect on packet processing. Specifically, fragmentation should be avoided.` ? Also, if SHOULD is kept, then please add guidance per: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
## COMMENTS (non-blocking) ### Section 1 Unsure whether the length paragraph 1 is really useful, describing what IOAM is useful but unsure about the classification details per RFC 7799 (hoping that RFC 9197 did that). Should 'external' (or 'outside of IOAM domain) be added to 'device' in `there are no protections against any device tampering with the data` ? As the last part looks like requirements, why not having a specific 'requirements' (or rather 'design goals') section *after* the threat analysis section ? ### Section 3 Should there be a reference to the security considerations of RFC 9197? ### Section 3.6 `The mechanisms in this document do not provide any mitigation against this threat.` should not be in the 'threat analysis', but more in the method specification. ### Sections 3.8 & 3.9 Similar comment for `Management plane attacks are not within the scope of this document; the network management protocol is expected to include inherent security capabilities. The integrity of exported data is also not within the scope of this document. ` this sentence should rather be in the lead text of section 3 to limit the scope of the threat analysis. Very similar comment for section 3.9 ### Section 4 and its subsections Should the text use the "TBD" value (or the suggested value from section 6.1) for `IOAM Trace-Type` (and others) in the figures ? Or should some text explain it ? ### Section 4.1 and others Just curious why a flag was not used and a specific trace-type was preferred. ### Section 6.2 When there are several code points in a registry, it is often useful to reserve some of them per RFC 8126 for 'private use' or 'experimental', or even FCFS. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)
Delayed IESG review to hopefuly have the companion YANG spec be ready as well for the same telechat.
Update: Thank you very much for addressing my concerns. I'm leaving the comments below for historical reasons. ----------------------- Thanks to Ben Kaduk for their (multiple) secdir reviews. I support Gunter's discuss, and his general comment about implementations (or the lack of). I support Eric's discuss, especially the part about the ICV occurring before the data. That doesn't lead to a nice flow through the system, does it? I'm curious as to why it was architected that way. Section 5: This is more for Eric V than the authors, per se. AES-GMAC provides data origin authentication, which can also be called 'source integrity'. While the tags are called authentication tags, they provide the ability to determine if the data being processed has been modified - data integrity. Using the term integrity protection is perfect.
Thank you to Yoshifumi Nishida for his TSV-ART reviews, and to the editors for their elpful response to address the issues. A minor nit was noted in the final TSV-ART review: "keeping in mind that only that IOAM subet would be integrity protected" - I think it should be "subset". I have one major comment: Requirements Language is used for the design considerations in section 1, this needs corrected. However, it seems likely that these considerations in the introduction were not specified to be compliance tested, and therefore this use of keywords could be replaced with non-RFC2119 language without disrupting the protocol operation. I have some minor comments, that I hope might improve readability for others: * I found this choice of words potnetially confusing: "an modify the fields of an IOAM Option-Type header in order to change or disrupt" - please consider if the words "in order" could be misinterpreted to mean the modification was in a sequence order, and rephrase if there could be ambiguity. * You might like to reconsider the form of words in these places: "Specifically, an attacker may replay a previously transmitted IOAM" as "Specifically, an attacker could replay a previously transmitted IOAM..." and "An attacker may delay some or all of the" as "An attacker might delay some or all of the" * The statement on being able to detect the integrity is presumably (?) statistical, so is this sentence actually correct, or is it more true to say that the Validator can assess the integrity and report whether it detects the meesage was intact or altered? " As a result, a Validator can detect if the integrity of IOAM-Data-Fields is intact or altered." Thanks again for an interesting and useful document and the care that has been taken with preparing this. Gorry Fairhurst (WIT AD)
Thank you for clearing my discuss and processing the comments.
I support Deb's and Éric's DISCUSS points, but otherwise am supportive of publication.