Geneve-based Firewall Metadata for Overlay Networks

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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:¶

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

2. 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).¶

2. 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 [RFC2119].¶

• 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 [RFC9197].¶

3. 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:¶

  "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 (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.¶

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

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

6. 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:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Option Class         |      Type     |R|R|R| Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Firewall Metadata                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |     Length    |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                              Value                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

8. Operational Considerations

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

10. 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".¶

11. References

Authors' Addresses