Telechat Review of draft-ietf-ippm-ioam-data-integrity-19
review-ietf-ippm-ioam-data-integrity-19-intdir-telechat-migault-2026-06-11-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

I am providing my review as these came to me while reading the document to
improve the readability of the document.

It is my opinion that the protocol ought to elucidate the application of GMAC
versus HMAC and justify the feasibility of having a precisely ordered list of
ICV generating nodes. I would advocate for the inclusion of an expression of
the list being evaluated, which would enable the verification of a non-valid
ICV against an invalid path or sub-path, rather than merely addressing modified
payloads. This could also help identify nodes that have failed to generate a
signature, potentially due to nonce repetition. Finally, I believe more thought
should be given to whether it is essential to provide a space for error
reporting.

Yours,
Daniel

Some more comments:

1. Introduction:

The "detectability problem" appears to be synonymous with an integrity check. A
failure in signature validation indicates that the field has been altered or
modified. The primary concern is that a modified field does not necessarily
mean it has been altered legitimately, and we still lack the ability to
identify who made the modification. Consequently, the application of a
signature or HMAC can demonstrate that the field has not been altered during
transmission. It can confirm that a modification has occurred, but it cannot
guarantee that the modification was made legitimately. I interpret this
differently than the point raised in bullet 1.

3. Threat Analysis

I believe we can adequately define the purpose and subsequently clarify only
what falls outside of that scope. Therefore, I feel that the initial paragraph
could be excluded.

I am of the opinion that the IOAM-Data-Field has yet to be defined. It would be
beneficial to specify what this field entails and the layer it pertains to.

"""
Since IOAM operates
within administratively controlled IOAM-Domains that define a trust
boundary, this reduces potential attack vectors and should naturally
mitigate off-path threats.
"""

In my opinion, the text above requires better articulation. While all nodes
within that domain may share the same level of trust, this does not imply that
the level of trust is 100%. An internal attacker could potentially execute an
off-path attack. I concur that off-path attacks are diminished, but I somewhat
disagree with the assertion that they are fully mitigated.

The phrase "illusion of a nonexistent failure" may require further
clarification. It appears to suggest a double negation, which would imply the
presence of an actual failure. I do not believe this is the intended meaning.

From the final paragraph, I gather that the only identified threat is a DDoS
attack. However, I naively believe that the consequences could encompass
anything triggered by IOAM data. I foresee potential issues such as misleading
diagnostics, resource exhaustion, denial of service, and processing overhead.

3.1 Modification: IOAM-Data-Fields

"""
An attacker that modifies the Trace-Type field ([RFC9197],
      Section 4.4.1) of the IOAM Trace Option-Type header can increase
      node processing overhead for IOAM-Data-Fields and increase on-the-
      wire overhead.
"""

I acknowledge my lack of understanding regarding Trace-Type; however, it may be
more effective to specify how the resource or wire overhead is augmented.

"""

      An attacker that modifies the RemainingLen field ([RFC9197],
      Section 4.4.1) of the IOAM Trace Option-Type header can prevent
      nodes from incorporating IOAM-Data-Fields.
"""

If I comprehend correctly, supplying a reduced remaining length hinders the
data parsing process. However, if IOAM data is integrated with other data, such
a modification could potentially influence the parsing of the packet. Should
this impact the parsing of the other data, I could foresee OAM being utilized
to facilitate an application Denial of Service (DoS).

section 5 Integrity Protection Method

The discussion regarding the utilization of symmetric keys prompts me to
consider the methods of key distribution, renewal, and protection. While
ensuring integrity protection may appear straightforward, the management of the
key does not seem trivial to me, and I anticipate that this topic will be
addressed at least somewhere in the paper.

From the preceding section, I gather that the integrity protection for
IOAM-Data-Fields is established using a sine nonce and a single Integrity Check
Value (ICV). According to the current text, the nonce remains unchanged. The
fact that the ICV is updated leads me to believe that the signature is
recalculated at each node for every payload, thereby ensuring integrity
protection is maintained by the last node. However, the final sentence refers
to a reconstruction of the integrity chain. I suspect that integrity-protected
payloads are iteratively encapsulated with a mutualized nonce. If this is
indeed the case, I think a brief explanation would provide clarity.

Another aspect that may require clarification or explicit mention is whether
each node possesses a single key and how data is managed by each node. At this
juncture, it remains unclear to me whether the data is updated by every node
along the path or if each node contributes its part, with aggregation occurring
solely at the destination node.

5.1 Key and Nonce Management

"""  Although GMAC
   supports all AES key sizes (i.e., 128, 192, and 256 bits), it is
   RECOMMENDED to use the longest key size when possible."""

I think it is better to point to documents that maintain the crypto so we have
a clear split. I woudl probably recommend
https://datatracker.ietf.org/doc/rfc8221/

""" Each key MUST
   be securely generated and fresh."""

We need a reference here.

"""
If
   a node receives a Nonce Length value other than 12, it MUST NOT
   change the contents of the Integrity Protection header and MUST NOT
   change the contents of the IOAM-Data-Fields.
"""

"""
When an encapsulating node reaches
   its maximum use of 256 distinct keys (i.e., see the Key ID field) and
   is also about to reach the limit of its key-specific counter, the key
   management system MUST rotate the keys of all IOAM nodes in the IOAM-
   Domain and notify any Validator with the new keys.
"""

I believe this approach may be overly forceful; our primary objective should be
to ensure that the correct key is accurately identified. In the worst-case
scenario, the IOAM Data could be rejected. It appears to me that the
provisioned keys should only require a single key ID for each node ID, and
provisioning would overwrite any previous key. This would, for instance, help
avoid duplication without necessitating the provisioning of all keys.

"""
An encapsulating node that participates in the integrity protection
   of IOAM-Data-Fields MAY retain on persistent storage the current key
   in use and the corresponding key-specific counter, such that a power
   interruption or system crash (or reboot in general) does not lead to
   nonce reuse.  If it is not possible for some reason, the
   encapsulating node MUST NOT reuse the key and the key management
   system MUST rotate the key before the encapsulating node resumes
   integrity protection.
"""

The text effectively emphasizes the necessity of considering a reboot. However,
I believe that storing every counter value will incur significant performance
costs. Therefore, this approach would only be feasible for IOAMs that are not
subjected to heavy loads.

5.2.  Integrity Protection of Header Fields

"""
Without such fields, IOAM-Data-Fields cannot be
   reliably interpreted.  As a consequence, the integrity of any
   immutable Option-Type header field MUST be protected.
"""

For interoperability, I think the immutable field sMUST be clearly and
explicitly be provided. I think the section 6.2 should be indicated.

"""
Since
   IOAM has no versions, it does not make sense to introduce versions in
   the integrity protection feature either.
"""

I would contend that it certainly makes sense. I believe the rationale is that
the versions are set up in such a way that they do not need to be included in a
specific field of the packet.

5.3.  Encapsulating Node

In this context, we are effectively utilizing GMAC as a HMAC. However, to my
knowledge, GMAC is not advised for such use, mainly due to its security being
contingent on the size of the message. In summary, we require a robust
justification for employing it beyond the scope of AES-GCM.

5.4.  Transit Node

"""
   A transit node MUST NOT generate a new nonce, as this would break the
   integrity chain and prevent validation of IOAM-Data-Fields
   contributed by previous nodes.  It MUST use the received Nonce field
   for its own GMAC operation.  A transit node MUST NOT reuse a nonce
   with the same key, as this is critical for GMAC security.  Therefore,
   it MUST be able to detect reuse of nonces with its current key.
   Details on how this detection is implemented are out of scope.  If a
   transit node receives a Nonce field that has already been used with
   its current key, it MUST NOT change the contents of the Integrity
   Protection header and MUST NOT change the contents of the IOAM-Data-
   Fields.  In other words, the transit node must not process the IOAM
   Integrity-Protected Option-Type.

 """

It appears to me that this text should be included in the Nonce management
section.

I now comprehend how encapsulation is executed. However, I find the design
somewhat precarious, as ICV validation can only occur if the validating node
possesses the complete ordered list of nodes. To validate any ICV, it is
crucial to ensure that immutable fields are thoroughly understood by all nodes,
which reinforces my suggestion to have them explicitly stated. I mention this
because the text reminds us that the Method ID must remain unchanged. I find it
somewhat disconcerting to have this reiterated here.

I have the impression that depending on the precise list of nodes that have
signed the IOAM data is fragile, as there may be varying interpretations of the
list if, for instance, a node does not support the method. The validator might
expect the node to participate in the ICV and could fail to execute the
integrity check. I believe we require a robust justification for why the list
of node IDs is not explicitly provided or why additional mechanisms do not
guarantee that the validator has a clear understanding of the nodes involved.

5.3.  Encapsulating Node
5.4.  Transit Node
5.5.  Decapsulating Node

I believe that these sections are repeated frequently, and I think we should
clarify how to: generate an ICV, validate an ICV, and identify the types of
nodes, which include the initial node, transit node, and validating node.

5.6.  Validator

"""
A validator is not vulnerable to key-nonce reuse, since the computed
   ICV remains internal.  However, a protection against replay attacks
   in general (more specifically, replay of old IOAM-Data-Fields) is
   still needed.  To this end, a Validator MUST be able to detect nonces
   already used with specific keys during validation to prevent replays.
   Details on how this detection is implemented are out of scope.  If a
   Validator receives a Nonce field that has already been used with a
   specific key during validation, it MUST consider the ICV as invalid
   and ignore the next steps.
"""

The initial statement appears to imply that the validator creates a GMAC and
subsequently verifies its own GMAC. While I believe this scenario could occur,
I do not consider it to be a common expectation. This perspective relates to
the definition of the nodes involved, in my view.

I contend that the reuse of a nonce impacts every node; therefore, the nonce
verification should be the responsibility of any node rather than being limited
to the validator. This leads me to question what actions a transit node should
take when it detects a reused nonce, and particularly how an error can be
reported. That node may not have been able to generate the ICV.