Geneve-based Firewall Metadata for Overlay Networks
draft-singh-macneil-geneve-firewall-metadata-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | PRASHANT SINGH , Erin MacNeil | ||
| Last updated | 2026-07-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-singh-macneil-geneve-firewall-metadata-00
Network Working Group P. Singh
Internet-Draft E. MacNeil
Intended status: Standards Track Hewlett Packard Enterprise
Expires: 2 January 2027 1 July 2026
Geneve-based Firewall Metadata for Overlay Networks
draft-singh-macneil-geneve-firewall-metadata-00
Abstract
This document specifies a mechanism for embedding security-related
metadata within the Geneve header (RFC 8926). It allows a security
Enforcement Point to attach a cryptographically signed, verifiable
attestation of how it handled a packet, so that downstream
Enforcement Points and tunnel endpoints can confirm that security
policy was actually executed on the data path -- detecting policy
bypasses and divergence between Enforcement Points that should agree
-- while each Enforcement Point continues to enforce its own policy
independently. This validation of execution complements the
management plane's validation of intent. The document presents two
operational models. The primary model is the "End-to-End Attestation
Model", fully compliant with RFC 8926, where an ingress tunnel
endpoint adds and cryptographically signs metadata, and an egress
endpoint verifies it. This enables downstream nodes to verify and
audit that policy was executed consistently, while still applying
their own policy independently. The second part of this document
presents a proposal for a future extension to the Geneve standard.
This proposed extension would allow trusted transit devices to
participate in the metadata chain, enabling a hop-by-hop "chain of
custody" for enhanced, real-time security responsiveness within the
data center fabric.
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."
Singh & MacNeil Expires 2 January 2027 [Page 1]
Internet-Draft Geneve Firewall Metadata July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Choice of Geneve for Encapsulation . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Firewall Use Case . . . . . . . . . . . . . . . . . . . . . . 5
4. DDoS Use Case . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Enforcement Model: Verify-or-Drop . . . . . . . . . . . . . . 8
6. Proposed Geneve Option for Firewall Metadata . . . . . . . . 9
6.1. Firewall Metadata Format . . . . . . . . . . . . . . . . 9
6.1.1. Firewall Metadata Sub-TLV Format . . . . . . . . . . 9
6.1.2. Firewall Metadata Sub-TLV Types . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Use of the Critical Option Bit . . . . . . . . . . . . . 14
7.2. Cryptographic Algorithm and Key Management
Standardization . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. HMAC Algorithm Agility . . . . . . . . . . . . . . . 14
7.2.2. Key Management . . . . . . . . . . . . . . . . . . . 15
7.3. Replay Attack Mitigation . . . . . . . . . . . . . . . . 16
7.4. Standardization of Alarm Codes . . . . . . . . . . . . . 16
8. Operational Considerations . . . . . . . . . . . . . . . . . 16
8.1. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 16
8.1.1. MTU in the End-to-End Attestation Model . . . . . . . 16
8.1.2. MTU in the Chain-of-Custody Model (Proposed
Extension) . . . . . . . . . . . . . . . . . . . . . 17
8.2. High-Performance Implementation Considerations . . . . . 17
9. Proposal for a Future Extension: The Chain-of-Custody
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Rationale and Benefits . . . . . . . . . . . . . . . . . 18
9.2. Proposed Modification to RFC 8926 . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Singh & MacNeil Expires 2 January 2027 [Page 2]
Internet-Draft Geneve Firewall Metadata July 2026
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
Singh & MacNeil Expires 2 January 2027 [Page 3]
Internet-Draft Geneve Firewall Metadata July 2026
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).
1.1. 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 [RFC7348]:* 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 [RFC8926]:* 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.
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].
Singh & MacNeil Expires 2 January 2027 [Page 4]
Internet-Draft Geneve Firewall Metadata July 2026
* *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.
Singh & MacNeil Expires 2 January 2027 [Page 5]
Internet-Draft Geneve Firewall Metadata July 2026
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.,
Singh & MacNeil Expires 2 January 2027 [Page 6]
Internet-Draft Geneve Firewall Metadata July 2026
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.
Singh & MacNeil Expires 2 January 2027 [Page 7]
Internet-Draft Geneve Firewall Metadata July 2026
- *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.
Singh & MacNeil Expires 2 January 2027 [Page 8]
Internet-Draft Geneve Firewall Metadata July 2026
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1. 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)).
6.1.1. Firewall Metadata Sub-TLV Format
Each piece of metadata within the Firewall Metadata option is encoded
as a sub-TLV with the following format:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Singh & MacNeil Expires 2 January 2027 [Page 9]
Internet-Draft Geneve Firewall Metadata July 2026
* *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.
6.1.2. Firewall Metadata Sub-TLV Types
The following Sub-TLV Types are defined.
6.1.2.1. 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:
o 0: Allow
o 1: Deny/Drop
o 2: Rate-Limit
o 3: Log
o 4: Forward (e.g., to a different service chain)
Singh & MacNeil Expires 2 January 2027 [Page 10]
Internet-Draft Geneve Firewall Metadata July 2026
* *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.
6.1.2.2. 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
Singh & MacNeil Expires 2 January 2027 [Page 11]
Internet-Draft Geneve Firewall Metadata July 2026
- 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:
o 0: Green (normal; within the configured rate)
o 1: Yellow (approaching the configured rate limit)
Singh & MacNeil Expires 2 January 2027 [Page 12]
Internet-Draft Geneve Firewall Metadata July 2026
o 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.
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.
Singh & MacNeil Expires 2 January 2027 [Page 13]
Internet-Draft Geneve Firewall Metadata July 2026
7.1. 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.
7.2. 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.
7.2.1. 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.
Singh & MacNeil Expires 2 January 2027 [Page 14]
Internet-Draft Geneve Firewall Metadata July 2026
7.2.2. 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 [NIST.SP.800-57].
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.
Singh & MacNeil Expires 2 January 2027 [Page 15]
Internet-Draft Geneve Firewall Metadata July 2026
7.3. 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.
7.4. 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.
8. Operational Considerations
8.1. 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.
8.1.1. 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:
1. The overhead of the outer IP and UDP headers.
2. The base Geneve header.
3. The maximum metadata size that a single ingress EP is configured
to add.
Singh & MacNeil Expires 2 January 2027 [Page 16]
Internet-Draft Geneve Firewall Metadata July 2026
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.
8.1.2. 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:
1. *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.
2. *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.
8.2. 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.
Singh & MacNeil Expires 2 January 2027 [Page 17]
Internet-Draft Geneve Firewall Metadata July 2026
1. *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.
2. *Metadata Transport:* The PHV, now enriched with the firewall's
decision, is passed along with the packet to the next stage in
the pipeline.
3. *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.
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.
9.1. 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.
Singh & MacNeil Expires 2 January 2027 [Page 18]
Internet-Draft Geneve Firewall Metadata July 2026
* *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.
9.2. 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 [RFC9197], 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.
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
Singh & MacNeil Expires 2 January 2027 [Page 19]
Internet-Draft Geneve Firewall Metadata July 2026
11.1. Normative References
[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>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/rfc/rfc8926>.
11.2. Informative References
[NIST.SP.800-57]
Barker, E., "Recommendation for Key Management: Part 1 -
General", NIST Special Publication 800-57 Part 1 Revision
5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/rfc/rfc7348>.
[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>.
Authors' Addresses
Prashant Singh
Hewlett Packard Enterprise
Email: prashant.singh@hpe.com
Erin MacNeil
Hewlett Packard Enterprise
Email: erin.macneil@hpe.com
Singh & MacNeil Expires 2 January 2027 [Page 20]