Geneve-based Firewall Metadata for Overlay Networks

Introduction In modern data centers, a significant volume of traffic is encapsulated in overlay protocols like Geneve. This includes both the high volume of "East-West" traffic between internal services and the "North-South" traffic that is routed to and from the data center edge. Securing this encapsulated traffic requires a distributed approach where policy is enforced at the tunnel endpoints. While these enforcement points (e.g., firewalls integrated into a hypervisor's vSwitch or running on a DPU) can enforce local policy, they lack a standardized way to share the security context of a packet with other security devices in the network path. This document specifies a new Geneve option to carry this security context as metadata. This metadata, inserted by an ingress tunnel endpoint (e.g., a vSwitch with a distributed firewall), provides a signed attestation of the packet's security disposition. This allows other nodes in the path to make more intelligent, context-aware decisions. The primary contribution is the verification model these attestations enable: rather than delegating trust to an upstream device, each Enforcement Point applies its own policy and uses the attested metadata to verify and audit that policy was executed consistently across the path. This validates execution on the data path and complements the control or management plane -- the centralized system(s) that provision and distribute security policy to each Enforcement Point, such as an SDN controller, orchestrator, or security policy manager -- which validates intent (that the correct policy was provisioned). It supports detection of policy bypasses and of action divergence scoped by Policy ID. This document describes two models for the use of this metadata:

The End-to-End Attestation Model (RFC 8926 Compliant): An ingress endpoint adds and signs metadata. Transit devices, such as intermediate firewalls in a service chain, MAY read this metadata. While these transit EPs MUST NOT modify the Geneve options, they MAY perform validation on the metadata. This can range from stateless "Conformance Checking" (e.g., dropping a packet that lacks required metadata) to full cryptographic verification of the HMAC signature, provided the EP has access to the relevant key. Once the metadata is verified, the transit EP can trust it and take immediate action. Such actions can include raising an alarm for a detected action mismatch, policy mismatch, or policy violation. The EP can also use the Policer State, Severity, and Threat ID information to track potentially malicious flows for DDoS mitigation purposes. This adds a significant layer of security within the path. The final egress endpoint then performs the ultimate verification to ensure end-to-end integrity. This model provides a verifiable, end-to-end statement of security context with robust options for intermediate validation and enforcement.
The Chain-of-Custody Model (Proposed Extension): This document also puts forth a proposal for a future extension to the Geneve standard. In this model, select, trusted transit devices would be permitted to add their own signed metadata blocks. This would create a hop-by-hop, verifiable audit trail, enabling more dynamic and granular security responses within the network fabric. This proposed extension is detailed in (#future-extension).

Choice of Geneve for Encapsulation The selection of Geneve as the encapsulation protocol for this framework was deliberate, based on its superior, built-in support for extensible metadata. While other overlay protocols exist, Geneve's design is uniquely suited to this use case.

VXLAN : The original VXLAN specification provides no native mechanism for carrying metadata. Its header is fixed, lacking a format for options or TLVs.
VXLAN-GPE: While VXLAN-GPE extended VXLAN to add a "Next Protocol" field, its primary purpose is to enable service chaining and new data-plane protocols, not to provide a generic container for arbitrary metadata TLVs.
Geneve : In contrast, Geneve was designed from its inception with a flexible, extensible option format. It provides a standardized way to insert one or more variable-length, typed options (TLVs) directly into the header. This makes it the ideal and most natural choice for carrying the kind of rich, structured security metadata defined in this document.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Enforcement Point (EP): A node in the network that applies security policy to packets (e.g., a firewall).
Chain of Custody: A verifiable record of the sequence of EPs that have processed a packet.
Firewall Metadata: Information related to the security processing of a packet, such as the action taken, the filter that matched, and the identity of the EP.
Security Metadata Domain: The set of Enforcement Points that share key material and namespace configuration for the firewall metadata defined in this document. The domain boundary is an operational decision: the operator defines which EPs participate by provisioning them with shared HMAC keys. An EP that has not been provisioned with the relevant key material is outside the Security Metadata Domain and MUST NOT be expected to produce or verify attestations. This concept is analogous to the "IOAM-Domain" defined in .

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 a Geneve TLV indicating the action taken (e.g., allow, deny, log), the policy that was applied, and its own identity. 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.
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:
Detection of Action Mismatches: The metadata allows for the detection of conflicting actions, scoped by the Policy ID (Sub-TLV Type 6). 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.

DDoS Use Case The generic metadata mechanism defined in this document is a powerful building block that can be applied to a wide range of use cases beyond the primary firewall verification scenario.

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 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 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.
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.

Enforcement Model: Verify-or-Drop Each enforcement point (EP) MUST apply its own security policy independently. Verification of upstream security metadata is an additional capability layered on top of independent enforcement; it is not a prerequisite for, nor a replacement of, an EP's own inspection. An EP never delegates its enforcement decision to an upstream EP based on the metadata it carries. A key property of this model is that the absence of an expected attestation is itself a security event. When an EP cannot verify the metadata it expects (because the attestation is missing, was stripped in transit, or fails the integrity check defined in (#security)), its behavior is determined by local policy:

Strict mode ("Verify-or-Drop"): Unverifiable or missing expected metadata is treated as absent, triggering a POLICY_VIOLATION_BYPASS alarm and, optionally, a packet drop. This is appropriate for high-security environments (e.g., PCI compliance zones).
Permissive mode: The EP logs the event, enforces its own policy independently, and forwards the packet. This is appropriate during migration, key rotation, or in multi-tenant environments where not all EPs are provisioned for all security domains.
Non-participant nodes: An EP that has never been provisioned with the relevant key material simply forwards the packet with the metadata intact. The metadata passes through opaquely, as any other Geneve option would.

In all cases, the EP enforces its own security policy regardless of whether it can verify the metadata.

Proposed Geneve Option for Firewall Metadata This document proposes a new Geneve option to carry firewall metadata. The option would be structured as a TLV, with a new Option Class to be assigned by IANA. The proposed format for the option is as follows:

Firewall Metadata Format The Firewall Metadata field is composed of a sequence of sub-TLVs, as defined in (#subtlv-format). When security verification is required, these sub-TLVs are grouped into authenticated blocks using the Authentication Tag sub-TLV (Type 5), which acts as a container. An Enforcement Point (EP) MUST append its authenticated block to the end of the option data. This creates a sequential, verifiable chain of attestations. Because blocks accumulate rather than overwrite, a verifier can parse the attestations from multiple EPs in a single packet and correlate their decisions (see (#ddos)).

Firewall Metadata Sub-TLV Format Each piece of metadata within the Firewall Metadata option is encoded as a sub-TLV with the following format:

Type (8 bits): The type of metadata being carried. The initial types are defined in this document.
Length (8 bits): The length of the Value field in bytes.
Reserved (16 bits): MUST be set to zero by the sender and ignored by the receiver.
Value (Variable Length): The data for the sub-TLV.

Firewall Metadata Sub-TLV Types The following Sub-TLV Types are defined.

Proposed Sub-TLV Types

Type 1: Filter Node ID:
- Length: 4
- Value: 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.
Type 2: Filter ID:
- Length: 4
- Value: A 32-bit identifier for the specific filter or policy rule that was matched by the packet.
Type 3: Filter Action:
- Length: 1
- Value: 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)
Type 4: Timestamp:
- Length: 8
- Value: 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.
Type 5: Authentication Tag (HMAC):
- Length: 16
- Value: A cryptographic signature to ensure the integrity and authenticity of the metadata added by a single EP. When an EP adds a block of sub-TLVs, this MUST be the final sub-TLV in that block. The HMAC is calculated over the entire sequence of sub-TLVs in the current EP Metadata Block, from the first sub-TLV to the Authentication Tag sub-TLV itself. For the calculation, the Value field of the Authentication Tag is temporarily zeroed out. The resulting HMAC is then truncated to 128 bits and placed in this field. The HMAC input MUST also include the Geneve Virtual Network Identifier (VNI), so that a signed block cannot be replayed onto a different packet or virtual network.
Type 6: Policy ID:
- Length: 4
- Value: 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.

Recommended Additional Sub-TLV Types For enhanced functionality and broader use cases, the following additional Sub-TLV types are recommended:

Type 7: Session ID:
- Length: 8
- Value: 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.
Type 8: Threat ID:
- Length: 4
- Value: A 32-bit identifier if the packet is associated with a known threat (e.g., from a threat intelligence feed).
Type 9: Severity:
- Length: 1
- Value: An 8-bit unsigned integer representing the aggregate severity, or intensity, of an event along the path (0 = informational, 255 = critical). Severity expresses magnitude, complementing the Threat ID (which threat) and Filter Action (the response taken). It is intended to be computed by aggregation rather than set from a single node's subjective opinion: an EP MAY raise the Severity it records when it observes corroborating evidence from multiple upstream EPs for the same flow (e.g., several distinct Filter Node IDs each reporting a Policer State of "red" for the same Session ID or Threat ID). Severity thus escalates monotonically along the path as evidence accumulates. An EP that raises Severity MUST do so by appending its own authenticated block with the new value and MUST NOT alter an upstream EP's block (see (#security)).
Type 10: Policer State:
- Length: 1
- Value: 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.
Type 11: Key ID:
- Length: 4
- Value: A 32-bit identifier for the cryptographic key used to generate the Authentication Tag. This sub-TLV MUST be included within the authenticated block of sub-TLVs if signing is enabled. It allows a verifier to select the correct key for signature validation.
Type 12: Metadata Size Exceeded:
- Length: 4
- Value: The 32-bit Filter Node ID of the Enforcement Point that failed to add its full metadata due to size constraints. This explicitly signals which EP in the chain encountered the issue.
Type 13: Metadata Rollover:
- Length: 4
- Value: The 32-bit Filter Node ID of the Enforcement Point that performed a "metadata rollover" action. This indicates that the EP verified, logged, and removed the preceding metadata chain before adding its own to conserve space.

Security Considerations The primary security consideration for this proposal is the integrity and authenticity of the firewall metadata. If an attacker can forge or modify this metadata, the entire "chain of custody" concept is compromised. To ensure a baseline of interoperable security, implementations of this specification MUST support HMAC-SHA256-128 (HMAC-SHA256 truncated to 128 bits) as the default authentication algorithm. Future versions of this specification may consider the inclusion of post-quantum secure algorithms as they become standardized. The use of this authentication tag is STRONGLY RECOMMENDED for any deployment. The keys used for the HMAC must be securely managed and distributed only to trusted enforcement points.

Use of the Critical Option Bit The high-order bit of the main Geneve Option Type field is the Critical (C) bit. Implementations of this specification SHOULD allow the setting of the C bit to be a configurable policy at the enforcement point. When the C bit is set on this option, it signals to any Geneve-aware node that processes the option (including intermediate Enforcement Points and the final tunnel endpoint) that understanding this security metadata is critical. If a receiving node does not understand the option, it MUST drop the packet. This enforces a "fail-safe" security posture, which may be desirable in high-security environments as it prevents potentially unverified traffic from being processed. Operators should be aware that enabling the C bit can have operational consequences. During a deployment or migration, if enforcement points begin setting the C bit before all Geneve-aware nodes in the path (including other EPs and tunnel endpoints) are upgraded to understand this option, the non-compliant nodes will drop traffic. Therefore, the decision to enable the C bit should be made based on the specific security requirements and operational maturity of the environment.

Cryptographic Algorithm and Key Management Standardization The integrity of the Authentication Tag sub-TLV, and thus the entire chain of custody, is critically dependent on the secure management of the cryptographic keys used for the HMAC.

HMAC Algorithm Agility To ensure a baseline of interoperable security, implementations of this specification MUST support HMAC-SHA256-128 (HMAC-SHA256 truncated to 128 bits) as the default authentication algorithm. However, to accommodate environments with higher security requirements, implementations SHOULD also support stronger algorithms such as HMAC-SHA384. The Key ID sub-TLV allows EPs to signal which key, and by extension which algorithm, is in use, enabling algorithm agility across a fabric. Future versions of this specification may consider the inclusion of post-quantum secure algorithms as they become standardized.

Key Management The distribution of keys MUST be performed via a secure, out-of-band control or management plane channel. In any practical deployment, especially in large-scale data centers, manual key management is insecure and operationally infeasible. Therefore, implementations of this specification SHOULD support automated, centralized key management protocols to handle the full lifecycle of the keys:

Secure Generation and Distribution: Keys must be generated with sufficient entropy and securely distributed to all trusted Enforcement Points (EPs) and verifiers without risk of interception.
Automated Key Rotation: Keys should be rotated at regular, defined intervals. To prevent service disruption during rotation, the system MUST support overlapping keys, where both the old and new key are considered valid for a short transition period. The Key ID sub-TLV is critical for enabling the verifier to select the correct key during this period.
Rapid Key Revocation: The key management system MUST provide a mechanism to immediately revoke and replace a key that is known or suspected to be compromised.

For further guidance on best practices, implementers should refer to established standards such as . To enhance security in multi-tenant or segmented environments, operators should have the ability to scope keys. Using a single, global key for the entire fabric is NOT RECOMMENDED as it creates a single point of compromise. Instead, a keying system could provide separate keys on a per-tenant, per-security-domain, or per-service-chain basis. Each such key scope effectively defines a distinct Security Metadata Domain ((#terminology)): only EPs provisioned with a given key participate in that domain and can produce or verify its attestations. The Key ID sub-TLV provides the necessary mechanism for verifiers to select the appropriate key for a given signature. A future extension to this specification MAY consider defining a protocol for dynamic, in-band key negotiation and establishment, similar in concept to IKE for IPsec. Such a mechanism could simplify deployments in highly dynamic environments but introduces significant protocol complexity and new security considerations that are beyond the scope of this foundational document.

Replay Attack Mitigation An attacker could capture a valid packet with signed metadata and reinject it into the network at a later time. The inclusion of the Timestamp sub-TLV (Type 4) is intended to mitigate this threat. Verifiers SHOULD maintain a policy to reject packets with timestamps that are outside of a small, locally configured time window. This prevents the acceptance of stale packets that could be part of a replay attack.

Standardization of Alarm Codes While this document describes the types of security violations that can be detected (such as a POLICY_VIOLATION_BYPASS), it does not standardize specific, machine-readable alarm codes for such events. A future document could define a registry of standardized codes (e.g., POLICY_ACTION_MISMATCH) and messages to promote interoperability between different vendors' monitoring and analysis systems.

Operational Considerations

MTU and Fragmentation Adding metadata to a Geneve packet increases its size, which can cause the outer IP packet to exceed the MTU of the underlay network. Since performing IP reassembly at intermediate network nodes is operationally infeasible, fragmentation of the outer packet MUST be avoided. The operational considerations related to MTU differ significantly between the two models presented in this document.

MTU in the End-to-End Attestation Model In the RFC 8926-compliant "End-to-End Attestation Model", only the single ingress tunnel endpoint adds metadata. This simplifies MTU management considerably. Network operators MUST configure the MTU of inner packets (e.g., on source VMs) to account for:

The overhead of the outer IP and UDP headers.
The base Geneve header.
The maximum metadata size that a single ingress EP is configured to add.

If an ingress EP determines that adding its desired metadata would exceed the configured option space, its behavior is determined by local policy. It SHOULD forgo adding the full metadata block and instead attempt to add only a Metadata Size Exceeded sub-TLV. If even this is not possible, the EP must either drop the packet or forward it without any metadata, based on its security policy.

MTU in the Chain-of-Custody Model (Proposed Extension) The "chain-of-custody" model, proposed as a future extension, reintroduces the challenge of cumulative metadata growth, as multiple EPs in a service chain may add metadata. In this model, the MTU of inner packets must be configured to account for the maximum anticipated metadata overhead from the entire service chain. When an intermediate EP in this model finds that adding its metadata would exceed the available space, it has two configurable strategies:

Forgo and Signal (Default): The EP SHOULD forgo adding its intended metadata and attempt to add only a Metadata Size Exceeded sub-TLV. This signals the failure to downstream verifiers and identifies the specific EP that encountered the size limit.
Rollover and Re-chain (Advanced): Alternatively, an EP MAY be configured to perform a "metadata rollover". In this mode, the EP first verifies the entire chain of existing metadata. If valid, it logs the verified metadata locally and then removes all preceding metadata from the Geneve option. It then adds its own metadata, along with a Metadata Rollover sub-TLV. This sub-TLV serves as a verifiable "seam" in the chain, informing the final verifier that a rollover occurred and that the full chain must be reconstructed from that node's local logs.

High-Performance Implementation Considerations A key consideration for this proposal is the ability to generate and sign metadata at line rate without impacting performance. This is readily achievable on modern SmartNICs, DPUs, and programmable ASICs using a template-based hardware pipeline model. This approach avoids per-packet software intervention for established flows. The process relies on an internal, programmable metadata structure, often called a Packet Header Vector (PHV) or packet descriptor, that accompanies the packet as it is processed by the hardware pipeline.

Firewall Stage: The firewall or ACL block performs its lookup. Instead of modifying the packet directly, it writes its results (e.g., Filter ID, Action) into designated fields within the PHV.
Metadata Transport: The PHV, now enriched with the firewall's decision, is passed along with the packet to the next stage in the pipeline.
Tunnel Encapsulation Stage: The encapsulation block reads the action from the PHV. If metadata is required, it reads the firewall results from the PHV, combines them with live data from other hardware resources (such as a high-precision clock for the Timestamp and a crypto engine for the HMAC), assembles the final Geneve option, and adds it to the packet.

This hardware-centric, template-based approach enables the creation of dynamic, per-packet metadata at line rate. Such pipelines are commonly exposed by programmable SmartNIC/DPU software development kits.

Proposal for a Future Extension: The Chain-of-Custody Model The End-to-End Attestation model, as described in this document, provides a robust and RFC 8926-compliant mechanism for verifying the security context of a packet as determined by the ingress tunnel endpoint. However, the restriction that transit devices MUST NOT modify Geneve options limits the potential for real-time, hop-by-hop security collaboration within the network fabric. This document therefore puts forth a proposal for a future extension to the Geneve standard that would relax this constraint for explicitly trusted devices. This proposed "Chain-of-Custody Model" would allow designated Enforcement Points (EPs) along the network path to append their own authenticated metadata blocks.

Rationale and Benefits Enabling a chain of custody would unlock several powerful capabilities:

Granular Path Visibility: A per-hop signed record shows exactly which EPs inspected the packet, what each decided, and when (via the Timestamp sub-TLV, Type 4), enabling precise localization of a bypass or action divergence to a specific hop rather than only detecting that one occurred somewhere on the path.
Enhanced Forensics and Auditing: A complete, hop-by-hop record of security actions taken on a packet provides an invaluable data source for forensic analysis after a security incident and for demonstrating regulatory compliance.

Proposed Modification to RFC 8926 To enable this model, a future revision of RFC 8926, or a new standards-track document, would need to introduce a mechanism to allow trusted devices to modify Geneve options. This could be achieved, for example, by defining a new "Trusted" bit in the Geneve option header or by specifying that EPs sharing a common, secure key management system are implicitly trusted to add to, but not modify, existing options from other EPs. This change would represent a significant evolution of the Geneve standard and requires careful consideration of the security implications. However, the capabilities it would unlock merit its consideration by the IETF community. The proposed model is conceptually similar to the In Situ Operations, Administration, and Maintenance (IOAM) framework defined in , which also uses a hop-by-hop approach to embed telemetry data within packets. Applying this proven concept to security metadata is a logical next step. In this multi-EP model, the per-EP Authentication Tag (Type 5) SHOULD additionally bind each EP's block to the preceding accumulated option data -- for example, by including the previous block's Authentication Tag (or a hash of the option data so far) in the HMAC input. This converts the independently signed blocks of the End-to-End Attestation Model into a cumulative, hop-by-hop chain, so that deletion, reordering, or cross-packet splicing of an upstream EP's block is detectable by the verifier. This binding is not required in the End-to-End Attestation Model, where a single EP adds a single block, and it changes only the bytes covered by the HMAC, not the sub-TLV wire format.

IANA Considerations This document requests IANA to assign a new Option Class from the "Geneve Option Class" registry for the firewall metadata defined in this document. This document also requests that IANA create and maintain a new registry called "Firewall Metadata Sub-TLV Types" for the Type field of the sub-TLVs defined in (#subtlv-format). The registration policy for new types should be "IETF Review".