Summary

  • draft-ietf-ippm-ioam-data-integrity-20 lets a trusted Validator recompute a cumulative AES-GMAC integrity chain and report whether modification was detected in declared protected fields.
  • A valid ICV does not prove that every expected Option-Type arrived, that a compromised node reported truthful local measurements, that exported data remained intact, that no delay occurred, or that all traffic was covered.
  • Automation should close on a typed evidence envelope: protected-set inventory, expected and observed participants, replay disposition, Validator provenance, export custody, coverage denominator and independent service readback.

The Validator receives an IOAM record, identifies the nodes that appear in it, retrieves their keys, replays the GMAC operations in order and compares the computed result with the ICV carried in the packet. The comparison succeeds. The console paints the path green.

The cryptography has answered a real question: under the Validator's current key, identity and replay state, it did not detect modification in the immutable fields included in the protected record.

The console has answered a different one: can we trust the path?

Those questions are not equivalent.

Revision 20 of draft-ietf-ippm-ioam-data-integrity, dated 19 July 2026, is an active IPPM Working Group Internet-Draft in the RFC Editor queue. It is awaiting its first editor; IANA records that the changed version needs review. The draft is mature enough to expose the mechanism and its threat boundaries, but it is still work in progress. Queue position does not prove a deployed implementation, interoperable key system, correct Validator, complete coverage or operational result.

That distinction matters because integrity products are sold with unusually expansive language. A tag that covers bytes becomes “trusted telemetry.” A trusted Validator becomes “independent verification.” A valid comparison becomes “proof of path.” The draft itself is more disciplined.

The ICV authenticates a declared calculation

The method creates protected versions of pre-allocated trace, incremental trace, Proof of Transit and edge-to-edge IOAM options. Each node that updates the chain has its own symmetric key. A deterministic 12-octet nonce carries a Key ID, an encapsulating-node identifier and a 64-bit counter. The encapsulating node starts the chain over selected immutable header fields and its own immutable IOAM data. Participating transit nodes fold the received ICV and their immutable contribution into another GMAC operation.

Only the latest ICV travels. The Validator reconstructs the sequence with the received fields and the keys associated with the apparent participants. For trace options, a node identifier must be present so the Validator can locate the corresponding key. The draft leaves that identity-to-key mapping outside its scope.

When the final equality holds, the result is precise: the reconstructed function returned the value received. It does not turn every field into fact. Mutable header fields are not integrity-protected. A node that adds no immutable data does not update the ICV. Some option types involve only the encapsulating node. The depth of the chain varies with the option.

“Valid” therefore needs parameters. Which namespace? Which Option-Type? Which method and masks? Which nonce and key epoch? Which apparent participants? Which Validator build and mapping version? Without them, the badge cannot be reproduced or bounded.

A participant can authenticate a lie about itself

The draft says compromised encapsulating or transit nodes can forge or drop packets. The chain prevents one participant from impersonating another or silently modifying another protected contribution, assuming keys and mappings are sound. It does not make a compromised node's own measurement honest.

A router can possess the correct key and report an invented queue depth under its own identity. It can omit a local event before constructing its contribution. It can drop a packet. The ICV may be perfectly valid because the false statement was authentic at the moment it entered the chain.

This is the old difference between provenance and truth. Provenance says who made the assertion and whether protected bytes changed. Truth requires a reason to trust the measurement process, calibration, software, configuration and incentives of that source. Cryptography can preserve an assertion; it cannot transform the source into an impartial witness.

The receipt should therefore separate authentic contribution from credible measurement. Device attestation, software provenance, configuration state, independent counters and cross-observer consistency belong outside the ICV result.

The trusted Validator is a control point

The Validator holds the key material and makes the final decision. The draft calls it a trusted entity and states the uncomfortable consequence directly: a compromised Validator can forge or modify IOAM data and produce incorrect validation results, and this method cannot prevent that behavior.

That is not a cryptographic flaw. It is an authority boundary.

If the same product selects the expected participants, owns the key map, computes the verdict and triggers remediation, its green result is not independent merely because it uses GMAC. The system has concentrated evidence definition, verification and action behind one administrative identity.

A defensible design records the Validator's software build, configuration hash, key-map version, deployment identity and decision policy. High-impact actions should require an external approval or a second observation plane. The Validator should emit a reproducible receipt, not a word that can only be trusted by trusting the Validator again.

What never arrived cannot be validated

The strongest boundary is absence. An on-path attacker can remove an entire IOAM Option-Type header. The draft says this mechanism does not mitigate that attack; the encapsulating protocol should provide the protection. A compromised node can also replace a protected option with its unprotected equivalent unless the Validator knows every namespace, encapsulating node and Option-Type that is supposed to be protected.

The ICV only covers the record that survived. It cannot authenticate a missing envelope.

This turns expected-set management into a first-class security control. Before validating bytes, the system needs an inventory: for this traffic class and policy generation, which protected namespaces and options should appear, which nodes are expected, and which unprotected options may coexist? Compare the expected set with the observed set. Only then evaluate the chain.

An empty telemetry record is not “nothing happened.” It may mean the packet was not sampled, the option was stripped, the namespace was unprotected, the device did not participate, export failed or policy never enabled the mechanism. Those states demand different outcomes.

Protection can coexist with its absence

The draft permits protected and ordinary IOAM options in the same domain. Multiple namespaces can coexist, one carrying a protected pre-allocated trace and another an unprotected trace. Operators may limit integrity insertion to a traffic subset to control processing cost. Only that subset is protected.

A valid packet is therefore not a coverage denominator. It cannot support “the path telemetry is protected” without evidence about how many eligible packets were selected, which flows and namespaces were excluded, and whether a policy change altered selection during the observation window.

This is where dashboards routinely overreach. They count valid samples but do not show the unsampled population. A thousand valid records can coexist with a critical flow that never carried the option. Coverage is a separate metric, not a property inherited from the samples that survived.

Integrity stops at the export boundary

The draft excludes management-plane attacks and the integrity of data exported to a receiving entity. It expects the management protocol and export format to provide their own security. Direct Export carries no IOAM-Data-Fields and must not use this protection method.

That leaves a custody handoff. A packet can arrive with a valid on-path ICV, then be parsed, normalized, transported, stored or aggregated incorrectly. A later analytics system may be looking at data that no longer has the original protected representation. The original verdict does not flow automatically through those transformations.

Preserve the raw protected record, the validation receipt and the export/storage transformations. Hash each handoff. Record who changed representation and why. If the receiving system cannot reproduce the validation or trace the transformation, its dashboard should say export integrity unproven, not recycle the packet's on-path status.

Direct Export is a second warning against label drift. It is related IOAM machinery, but it carries a different evidence shape. Similar names are not permission to reuse a security claim.

Authentic bytes can still arrive late

Delay is also outside the method. An attacker can selectively delay packets with IOAM data and manufacture the appearance of congestion. The ICV may remain valid because no protected byte changed.

This matters when automation acts on telemetry. A valid but delayed queue report can trigger rerouting after the condition has disappeared. A deliberately delayed sample can make a healthy path look impaired. The draft notes that redundant paths do not solve the particular problem when the purpose is to measure a specific path.

Freshness needs its own evidence: capture and validation time, permitted age, clock quality, sequence or counter continuity, and comparison with independent delay/loss observations. Replay protection is not enough. A packet can be unique and still be stale for the decision being made.

Replay protection is state, not a slogan

GMAC nonce reuse with the same key is catastrophic. Nodes and Validators must detect reuse; the replay window determines how much legitimate reordering is tolerated. Reordered or duplicate packets that fall into this behavior are not processed for integrity protection and receive no IOAM data.

The operational obligation is substantial. Counters, Key IDs, node identities and key epochs have to survive rotation and restart. If a node cannot preserve its state through a reboot, the old key must not be reused; rotation must occur before protection resumes. Old keys must never be redistributed. Node-ID-to-key mapping and most key-distribution mechanics are left to the implementation.

A bare valid result hides all of this state. The receipt needs the key epoch, counter, replay disposition and the policy version that interpreted reordering. It must distinguish valid, replay detected, mapping unknown, key epoch unavailable and not processed. Treating the latter four as missing samples silently biases the remaining data toward success.

The evidence envelope

A useful validation receipt begins with the claimed set. Record the IOAM Domain, Namespace-ID, protected Option-Type, method, covered-field mask, traffic-selection rule and packet identity. Record expected and observed participants and options separately.

Then record the computation: nonce, non-secret identifiers, Key ID, key epoch, node-to-key map version, replay-window disposition, Validator identity, software build, configuration digest, validation time and exact result. Never expose secret keys.

Next record custody. Link the original protected bytes, decapsulation event, export channel, transformation steps, stored representation and consumer query. Preserve hashes and attribution at every handoff.

Finally record reality outside the chain: delay, loss, path corroboration, customer-service metrics, action taken, authority for that action, rollback trigger and observed outcome. The ICV result should be one field in this receipt, not its title.

Typed outcomes help: valid_for_declared_set, invalid, replay_detected, expected_option_missing, identity_mapping_unknown, validator_provenance_unverified, export_integrity_unproven, coverage_partial and service_outcome_pending. Green and red are too small for the evidence.