IOAM Data Fields for Firewall and Security Metadata

4.1. Filter Node ID (32-bit)

A 32-bit opaque identifier for the enforcement point that inserted the metadata. The value is unique within the administrative domain and assigned via the management plane. Note that while IOAM defines a node_id, this field allows for a specific identifier for the security function if distinct from the forwarding node.¶

4.2. Filter ID (32-bit)

A 32-bit identifier for the specific filter or policy rule that was matched by the packet.¶

4.3. Filter Action (8-bit)

An 8-bit value indicating the action taken by the firewall. Examples include:¶

• 0: Allow¶

• 1: Deny/Drop¶

• 2: Rate-Limit¶

• 3: Log¶

• 4: Forward (e.g., to a different service chain)¶

4.4. Timestamp (64-bit)

A 64-bit timestamp in NTP format indicating when the action was taken. This format is a 64-bit unsigned fixed-point number, with the integer part in the first 32 bits and the fractional part in the last 32 bits.¶

4.5. Policy ID (32-bit)

A 32-bit opaque identifier that links the enforcement action to a named security profile. While the Filter ID identifies a specific rule on a node (the "what"), the Policy ID identifies the security profile that the rule is part of (the "why"). This is critical for auditing and compliance. For example, this ID could represent a profile named pci-dss-v4.0, tenant-blue-web-tier, or iot-device-isolation. A central management system would be responsible for mapping these opaque 32-bit IDs back to their meaningful profile names.¶

4.6. Session ID (64-bit, OPTIONAL)

A 64-bit unique identifier for the flow or session to which the packet belongs. This allows for easier correlation of metadata across multiple packets of the same flow. This identifier is typically a 64-bit hash of the packet's 5-tuple (source/destination addresses, protocol, and source/destination ports). The specific hash function is implementation-dependent; the resulting ID is treated as an opaque value used for correlation.¶

Session ID is OPTIONAL. It provides explicit per-flow correlation, which is most valuable for forensic correlation of benign (non-threat) traffic, where no Threat ID is present to group on. Threat ID ((#threat-id)) and Session ID correlate different things and do not substitute for one another: Threat ID groups packets by which threat they match, while Session ID groups packets by which flow they belong to. In encodings where space is constrained (the compact trace-bit profile, (#enc-b)), Session ID MAY be omitted; in that case per-flow correlation falls back to the existing IOAM flow context and the underlay 5-tuple, and DDoS aggregation relies on the Threat ID in the DDoS word.¶

4.7. Threat ID (32-bit)

A 32-bit identifier if the packet is associated with a known threat (e.g., from a threat intelligence feed).¶

4.8. Severity (8-bit)

An 8-bit unsigned integer representing the aggregate severity, or intensity, of an event along the path. Severity expresses magnitude ("how significant is this"), complementing the Threat ID (which identifies which threat) and the Filter Action (which records the response taken). A value of 0 is informational; 255 is critical.¶

Severity is intended to be computed by aggregation rather than set from a single node's subjective opinion. An Enforcement Point MAY raise the Severity it records when it observes corroborating evidence from multiple upstream EPs for the same flow -- for example, multiple distinct Filter Node IDs each reporting a Policer State of "red" ((#policer-state)) for the same Session ID or Threat ID. In this way Severity escalates monotonically along the path as evidence accumulates, giving downstream nodes and collectors a ready-made gradient of how distributed and intense an event is, without each node having to re-derive it.¶

An EP that raises the Severity MUST do so by appending its own data fields with the new value; it MUST NOT alter the fields contributed by an upstream EP, so that the integrity of each EP's contribution ((#integrity)) is preserved.¶

4.9. Policer State (8-bit)

An 8-bit enumerated value reflecting the instantaneous congestion state of a policer or rate-limiter at the enforcing node. Unlike Severity, this is an objective, locally-measured fact about a single node:¶

• 0: Green (normal; within the configured rate)¶

• 1: Yellow (approaching the configured rate limit)¶

• 2: Red (exceeding the configured rate limit)¶

Values 3 through 255 are reserved.¶

4.10. Handling Metadata Overflow

This namespace does not define specific data fields for indicating metadata space exhaustion. Instead, implementations MUST utilize the standard Trace Option-Type Flag: Bit 0 (Overflow) as defined in [RFC9197], Section 4.2. When an IOAM node cannot add its security metadata due to lack of space in the packet, it MUST set this Overflow flag to indicate that the trace data is incomplete.¶

5.1. Encoding A: Opaque State Snapshot

This document specifies the IOAM "Opaque State Snapshot" field defined in [RFC9197] (signaled by IOAM-Trace-Type bit 22) as the primary encoding. This field exists to carry arbitrary, schema-defined per-node state, and consists of a 1-octet Length, a 24-bit Schema ID, and a variable-length opaque data block.¶

Because bit 22 is already defined, this encoding consumes no new Trace-Type bits. It is carried as part of each node's node-data within a Trace Option-Type, so it inherits the hop-by-hop ICV chaining of (#integrity) for free, and its variable-length block can carry the full-size fields of (#fields), including the 64-bit Session ID.¶

The one consideration it introduces is schema distribution. [RFC9197] leaves Schema ID distribution to an out-of-band mechanism, so the metadata is not self-describing on the wire. To make it interoperable rather than operator-private, this document defines a single fixed schema for the Security_Metadata namespace and seeks a Schema ID assignment for it ((#iana-schema)); within the Security Metadata Domain the schema is provisioned alongside the namespace configuration and per-node keys that are already required.¶

The schema places the fields in the following order: Filter Node ID, Filter ID, Policy ID, the packed Action/Severity/Policer word, Timestamp, Threat ID, and -- when present -- Session ID.¶

5.2. Encoding B: Packed IOAM-Trace-Type Bits (Compact Profile)

This encoding defines new IOAM-Trace-Type bits (from those available for assignment via the IETF Review process [RFC9197]), each signaling a fixed 4-octet word of security data:¶

• Firewall word 1: Filter Node ID (32 bits).¶

• Firewall word 2: Filter ID (32 bits).¶

• Firewall word 3: Filter Action (8 bits) + Policy ID (24 bits).¶

• DDoS word: Threat ID (16 bits) + Severity (8 bits) + Policer State (8 bits).¶

Timestamp reuses the existing IOAM timestamp data fields [RFC9197]. Session ID is omitted ((#session-id)); per-flow correlation falls back to the IOAM flow context and the underlay 5-tuple, and DDoS aggregation uses the Threat ID. The profile therefore requires four new Trace-Type bits (or three, if the deployment reuses the existing IOAM node_id in place of a distinct Filter Node ID).¶

It is compact and fixed-format, suiting high-rate hardware data paths, and inherits the ICV chaining of (#integrity). Its principal cost is that it permanently consumes scarce, globally shared Trace-Type bits, giving it the highest IANA and working-group cost of the three. To avoid spending a new bit on the DDoS word, an implementation MAY instead carry it in the existing IOAM "namespace specific data" field [RFC9197], at the cost of consuming that single namespace slot.¶

5.3. Encoding C: Dedicated Option-Type or Sub-TLV Structure

This encoding defines a dedicated, TLV-structured carriage for the security metadata, analogous to the Sub-TLV design in the companion Geneve specification. Each field or group of fields is a type-length-value element, making it self-describing on the wire via an IANA type registry, supporting optional and variable fields (including the full-size Session ID), and avoiding any Trace-Type bits.¶

Its cost is the heaviest standardization effort of the three: it requires a new IOAM Option-Type or an agreed sub-TLV structure plus an associated IANA registry. A new, custom Option-Type is also not automatically covered by the Integrity-Protected Option-Types of [I-D.ietf-ippm-ioam-data-integrity]; to retain the integrity leverage it would need to be registered in that document's "IOAM Integrity Protection Methods" registry, and until then does not inherit the hop-by-hop ICV chaining for free.¶

5.4. Comparison and Discussion

The three encodings trade standardization cost against flexibility. Encoding A consumes no new Trace-Type bits, can carry all fields at full width, and inherits the integrity chain-of-custody of (#integrity) for free; its main cost is schema distribution, for which this document defines a fixed schema whose registration mechanism is left to working-group discussion ((#iana-schema)). Encoding B offers a compact, fixed-format hardware encoding at the cost of new, globally shared Trace-Type bits and reduced field widths. Encoding C offers self-describing, registry-based interoperability at the cost of the heaviest standardization effort.¶

For concreteness, this document specifies Encoding A in full and uses it as the primary encoding. The authors believe it offers the best balance for an initial specification, but the choice among the three -- and whether more than one should ultimately be standardized -- is left open for working-group discussion, and a future revision will record the resulting consensus.¶

6.1. Firewall Use Case

The primary use case for this metadata is to allow an Enforcement Point (EP) to embed a verifiable attestation of a packet's security disposition within the packet itself. This allows downstream nodes to verify and audit that security context. Each EP MUST apply its own security policy independently; the metadata enables cross-correlation and auditing of those independent decisions, not delegation of enforcement. These enforcement points (EPs) can take several forms:¶

• Virtual Switches (vSwitches) with integrated firewalling¶

• Cloud-native firewalls (e.g., security groups)¶

• SmartNICs/DPUs offloading security functions¶

• Service-chained virtual or physical firewalls¶

Each of these nodes can inspect the packet and insert IOAM data fields indicating the action taken (e.g., allow, deny, log), the policy that was applied, and its own identity. As is inherent to IOAM trace data, each EP appends its own fields, so a downstream node sees the accumulated attestations of all EPs on the path and can correlate them. A downstream node (e.g., the destination host, a network tap, or another firewall) can then be programmed to inspect this metadata. The downstream node does not trust the upstream decision in place of its own; it enforces its own policy and uses the metadata to verify and audit consistency across EPs.¶

This mechanism complements, rather than replaces, the centralized control or management plane. The management plane validates intent (that the correct policy was provisioned to each EP); this metadata validates execution (that the policy was actually applied on the data path). This is valuable because:¶

• Intent may be provisioned correctly while execution diverges (e.g., a software bug, stale rule, or hardware fault).¶

• Out-of-band validation of execution is costly (packet sampling, log analysis), less reliable (clock skew and race conditions when correlating events across EPs), and incomplete (bounded by the sampling rate).¶

This enables several key security capabilities:¶

• Verification of Enforcement: The downstream node can verify that the packet has been stamped by all expected security nodes, proving it passed through all required checkpoints. This differs from proof-of-transit mechanisms (such as the IOAM POT Option-Type [RFC9197]), which prove only that a packet traversed a predefined set of nodes: a node can satisfy proof-of-transit while its security function is disabled, fail-open, or applying a stale rule. By attesting the action actually taken (the Filter Action and Policy ID), this metadata validates that the security function executed and records what it decided, not merely that the node was on the path.¶

• Detection of Policy Bypasses: If a packet arrives missing a TLV from an expected enforcement point, it indicates a potential bypass due to misconfiguration, a policy routing error, implementation failure, or a malicious attack. This capability enables alarms such as:¶

  "Policy violation detected: Expected inspection from node
   0x192A44B1 (FW02-Datacenter-Core) is missing, indicating a
   bypass -- POLICY_VIOLATION_BYPASS."
  

  ¶

• Detection of Action Mismatches: The metadata allows for the detection of conflicting actions, scoped by the Policy ID ((#policy-id)). Divergence is interpreted as follows:¶

  • Same Policy ID, different Action -> ALARM. If two EPs both reference the same Policy ID but record conflicting actions for the same packet (e.g., one ALLOW, one DENY), this indicates that two EPs that SHOULD agree do not -- typically due to a failed configuration push, stale rules, or compromise. This is reported as a POLICY_ACTION_MISMATCH:¶

    "Policy violation detected: Mismatching action from node 0x192A44B1 (FW02-Datacenter-Core) (allowed a packet which should have been dropped) -- POLICY_ACTION_MISMATCH."¶

  • Different Policy ID, different Action -> no alarm. If the EPs reference different Policy ID values, they are applying different policies at different points in the hierarchy (e.g., a perimeter allow policy and a downstream microsegmentation policy). An ALLOW/DENY divergence here is intentional policy layering and does NOT trigger an alarm.¶

• Auditing and Compliance: The collected metadata can be stored for subsequent analysis, enabling cross-vendor auditing, compliance verification, and supporting zero-trust security models.¶

In cases of detected policy bypass or action mismatch, the Enforcement Point can utilize IOAM Direct Export [RFC9326] to immediately send the conflicting packet headers and metadata to a security collector for forensic analysis, even if the packet itself is subsequently dropped.¶

6.2. DDoS Use Case

• Inband Metadata-Driven Mitigation: Because the threat metadata travels inband with the packets themselves, a downstream node can act directly on each marked packet, using the embedded signal to drive its own resource-allocation, scheduling, and state-retention decisions for that traffic.¶

• Distributed DDoS "Heat Map" and Real-time Mitigation: The metadata can be used to create a distributed "heat map" of a DDoS attack. An EP acting as a policer/rate-limiter, when experiencing a high rate of traffic (above configured allowed limits), can embed its Filter Node ID, its Policer State (e.g., "red"), Threat ID, and Session ID into the metadata of the (allowed) packets it forwards. This provides a granular, per-packet signal about network stress. The division of labor across these fields is deliberate: Threat ID identifies what the traffic is, Policer State is each node's objective report of its own congestion, and Severity is the aggregate magnitude a downstream node computes from many such reports. This enables a powerful two-tiered analysis model:¶

  • Tactical Mitigation: A downstream aggregation EP can monitor this metadata. If it observes a "red" Policer State from multiple distinct upstream Filter Node IDs for the same flow (e.g., matching the same Session ID, Filter ID, or Threat ID), it can raise the Severity accordingly ((#severity)) and perform immediate, localized mitigation, such as shunting the flow to a scrubbing appliance or applying a more aggressive filter. Because Severity escalates as corroborating reports accumulate, a single threshold on Severity lets further-downstream nodes act without re-counting the underlying reports.¶

  • Strategic Analysis: Concurrently, this metadata can be exported via telemetry (e.g., using IOAM Direct Export [RFC9326]) or packet mirroring to a central controller, which aggregates the data from all EPs to build a global, real-time visualization of the attack's path and intensity, enabling strategic response and detailed forensic analysis. This provides a valuable piece of telemetry to the central controller. The message can effectively say, "A distributed attack with Threat ID 123 has been detected, originating from sources A, B, and C, and flowing towards target Y." This provides the central controller with a real-time "attack path," allowing it to construct a global "attack graph" and make more intelligent, strategic decisions.¶

• Intelligent Load Balancing: Downstream load balancers and routing nodes can utilize the Policer State or Severity metadata to dynamically route traffic away from stressed security nodes or congested paths. This enables both security and routing elements to use the security signal as a routing metric, optimizing network performance and resilience by steering traffic toward less-stressed or alternate routes. This allows for real-time, distributed, and autonomous mitigation of DDoS and overload scenarios.¶

9.1. IOAM Namespace-ID

IANA is requested to assign a new IOAM Namespace-ID for "Security_Metadata" from the "IOAM Namespace-ID" registry.¶

9.2. Security Metadata Schema ID (Encoding A)

For the Opaque State Snapshot encoding ((#enc-a)), IANA is requested to assign a Schema ID identifying the fixed Security_Metadata schema defined in this document (the field order given in (#enc-a)). Because [RFC9197] scopes Schema IDs to an IOAM-Namespace and does not define a global Schema ID registry, the exact registration mechanism is an open item for working-group discussion; one option is to record the assignment within the Security_Metadata namespace definition.¶

9.3. IOAM-Trace-Type Bits (Encoding B)

If the compact trace-bit profile ((#enc-b)) is adopted, IANA is requested to assign new bits in the "IOAM Trace-Type" registry, via the IETF Review process, for the firewall and DDoS words defined in (#enc-b).¶

9.4. Security Metadata Type Registry (Encoding C)

If the dedicated TLV encoding ((#enc-c)) is adopted, IANA is requested to create a "Security Metadata Type" registry enumerating the field types defined in (#fields); and -- to retain integrity protection -- a corresponding entry would be required in the "IOAM Integrity Protection Methods" registry defined in [I-D.ietf-ippm-ioam-data-integrity].¶

11.1. Normative References

[I-D.ietf-ippm-ioam-data-integrity]

Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman, "Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-integrity-19, 11 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-19>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9197]

Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.

11.2. Informative References

[RFC9326]

Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, <https://www.rfc-editor.org/rfc/rfc9326>.