| Internet-Draft | NASM | June 2026 |
| Li & Cui | Expires 20 December 2026 | [Page] |
Operational analysis, troubleshooting, validation of network defense functions, and exchange of collected traffic evidence rely on attack samples that are consistently described and can be processed across operators, vendors, and research tools. Today, such samples are often represented by proprietary labels, partial traffic captures, flow exports, log bundles, or local database schemas, which makes comparison, reproduction, and automated processing difficult.¶
This document defines a YANG data model for network attack sample metadata. The model describes the sample identity, collection context, attack characteristics, data-content summary, anonymization status, and reproducibility information associated with packet, flow, session, log, or payload data. The model is intended to complement IPFIX, IODEF, PCAP/PCAPng-based operational data, and collected data manifests by defining metadata for the attack sample itself.¶
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 20 December 2026.¶
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.¶
Network attacks continue to grow in volume, sophistication, and operational impact. Operators need to correlate observations, troubleshoot incidents, validate mitigation functions, exchange selected evidence, and compare operational tools across heterogeneous networks. These activities rely on high-quality samples of observed attack behavior, together with enough metadata to understand how the sample was collected, sanitized, represented, and interpreted.¶
Today, there is no standardized way to describe, structure, label, archive, or share such attack samples in a consistent and interoperable manner. Samples are commonly stored as local packet captures, flow exports, log bundles, or data-set entries with proprietary labels. Important context such as observation point, topology, collection device, affected service, anonymization status, data-source type, and reproduction conditions is often missing or encoded in non-machine-readable form. This makes it difficult to reuse samples across tools, validate mitigation behavior, or exchange operational evidence between operators and tool vendors.¶
Existing IETF work covers related but different aspects of this problem. IPFIX [RFC7011] defines export of flow information. IODEF [RFC7970] describes incident objects. The Collected Data Manifest [I-D.ietf-opsawg-collected-data-manifest] describes metadata for collected operational data packages. NMOP work on network anomaly semantics [I-D.ietf-nmop-network-anomaly-semantics] and network incident management [I-D.ietf-nmop-network-incident-yang] can consume or reference attack samples as operational evidence, but those documents do not define a sample-level metadata model for packet, flow, session, log, or payload artifacts. This document complements those efforts by defining a YANG data model for the metadata of the attack sample itself.¶
The model provides a common, extensible framework to represent:¶
Attack sample metadata and versioning¶
Attack classification, behavior, and lifecycle stages¶
Data content (packet, flow, session, payload)¶
Reproducibility information (environment, tools, parameters)¶
Interoperability with IPFIX, IODEF, collected data manifests, PCAP/PCAPng data, and operational analysis tools¶
This model enables shareable, analyzable, reproducible, and machine-readable samples for operational analysis, incident support, mitigation validation, ML-based evaluation, rule validation, and data-set management.¶
The Operations and Management Area Working Group (OPSAWG) develops operationally useful specifications, including YANG data models and mechanisms for operational data exchange, when the work is not better handled by a more specialized working group. This document is scoped to that OPSAWG role. It does not define a new attack-detection algorithm, a new DDoS mitigation protocol, or a threat-intelligence exchange protocol. Instead, it defines an operational metadata model that can be used by collectors, management systems, controllers, analysis tools, and data repositories to describe attack samples and the data artifacts associated with them.¶
The model is intended to be used with, and not replace, the following work:¶
The OPSAWG collected data manifest can describe broader data collection packages, while this model describes the attack sample contained in, or referenced by, such packages.¶
IPFIX records, packet captures, session logs, and application logs can be referenced or summarized by the data-content part of this model.¶
IODEF can describe an incident object, while this model can describe a packet, flow, session, or log sample associated with that incident.¶
NMOP anomaly and incident models can reference or consume samples described by this model, without this document redefining anomaly semantics or incident lifecycle management.¶
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 BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Attack Sample: A structured collection of network data (packet, flow, session, log, or payload metadata) that represents one or more attack behaviors, together with labels and operational context.¶
Operational Attack Sample: An attack sample used for operational analysis, mitigation validation, data-set management, or evidence exchange.¶
This document defines a unified data model for describing network attack samples with operational context. The architecture is YANG-based, lightweight, interoperable with existing IETF standards, and intended for operational analysis, mitigation validation, ML evaluation, sample archiving, verification, and sharing. The attack sample description is composed of five core components: * Sample Metadata * Collection Context (time, device, environment) * Attack Context (path, type, stage, technique, affected service) * Data Content (packet, flow, session, payload) * Reproducibility Context (tools, parameters, data-set version, replay or generation conditions) These components form a self-contained, machine-readable attack sample object that complements but does not overlap with IPFIX, IODEF, collected data manifests, or packet-capture formats.¶
+--------------------------------------------------------------------------+
| Network Attack Sample Object |
| |
| +-------------------+ +---------------------------------------------+ |
| | 1. Sample Meta | | 2. Collection Context | |
| | - ID, Version | | - Collection Time (Start/End) | |
| | - Author/Source | | - Collecting Device (Vendor, Type, OS) | |
| | - Usage/License | | - Observation Point / Topology | |
| | - Anonymization | | - Data Source (PCAP/Flow/Session/Log) | |
| +-------------------+ +---------------------------------------------+ |
| |
| +--------------------------------------------------------------------+ |
| | 3. Attack Context | |
| | - Attack Path (source -> target -> lateral -> C2 -> exfiltration) |
| | - Attack Category / External Taxonomy Reference | |
| | - Lifecycle Stage (recon -> exploit -> C2 -> exfiltration) | |
| | - Target Vulnerability / Affected Service | |
| +--------------------------------------------------------------------+ |
| |
| +--------------------------------------------------------------------+ |
| | 5. Reproducibility Context | |
| | - Dataset Version / Generation Tool / Replay Parameters | |
| | - Sanitization and Anonymization Procedure | |
| | - Validation Result References | |
| +--------------------------------------------------------------------+ |
| |
| +--------------------------------------------------------------------+ |
| | 4. Data Content Description | |
| | - Packet-level (Headers, Payload, Fingerprints) | |
| | - Flow-level (IPFIX-compatible statistics) | |
| | - Session-level Behavior (Timing, Rate, Direction, Ratios) | |
| | - Traffic Features (Entropy, Flag Patterns, Unusual Behavior) | |
| +--------------------------------------------------------------------+ |
| |
+--------------------------------------------------------------------------+
|
v
Interoperability Layer (IPFIX / IODEF / Data Manifest / PCAP)
Figure 1: Architecture Diagram
¶
Collection Context provides when, where, and by which device the sample was captured.¶
Attack Context describes how the attack behavior appears and how it is classified.¶
Data Content is the raw network evidence (packet/flow/session).¶
Reproducibility information ensures the sample can be regenerated for verification.¶
IPFIX provides flow data used in Data Content.¶
The Collected Data Manifest provides device and collection metadata that can be reused by Collection Context.¶
NMOP anomaly and incident models can reference samples described by this model as operational evidence where applicable.¶
IODEF incidents can be generated from, or linked to, labeled attack samples.¶
This section defines the core logical data model for Network Attack Sample Description in accordance with YANG 1.1 RFC7950 [RFC8340]. The model is modular, reusable, and compatible with IPFIX [RFC7011], the Collected Data Manifest [I-D.ietf-opsawg-collected-data-manifest], IODEF [RFC7970], packet-capture data, and operational analysis tools. The model is structured into five groupings that represent the logical components of an attack sample: * sample-metadata * collection-context * attack-context * data-content * reproducibility-context¶
The sample-metadata grouping provides unique identification and management information for an attack sample.¶
grouping sample-metadata {
leaf sample-id {
type string;
description
"Unique identifier for the attack sample. A UUID is RECOMMENDED.";
}
leaf sample-version {
type string;
description
"Version identifier of the attack sample.";
}
leaf sample-name {
type string;
description
"Human-readable name of the attack sample.";
}
leaf description {
type string;
description
"Detailed description of the attack scenario.";
}
leaf creator {
type string;
description
"Creator or organization that produced the sample.";
}
leaf creation-time {
type yang:date-and-time;
description
"Time when the attack sample was created.";
}
leaf usage-scope {
type enumeration {
enum training;
enum testing;
enum analysis;
enum rule-verification;
enum research;
}
description
"Intended usage of the attack sample.";
}
leaf anonymization {
type enumeration {
enum none;
enum partial;
enum full;
}
description
"Level of anonymization applied to the sample.";
}
}
¶
## collection-context The collection-context grouping describes when, where, and by which device the attack sample was collected.¶
grouping collection-context {
leaf collection-start-time {
type yang:date-and-time;
description
"Start time of the data collection interval.";
}
leaf collection-end-time {
type yang:date-and-time;
description
"End time of the data collection interval.";
}
leaf collecting-device-type {
type enumeration {
enum router;
enum switch;
enum firewall;
enum probe;
enum host;
enum controller;
}
description
"Type of device that collected the traffic.";
}
leaf device-vendor {
type string;
description
"Vendor of the collecting device.";
}
leaf device-model {
type string;
description
"Hardware model of the collecting device.";
}
leaf os-version {
type string;
description
"Operating system or firmware version.";
}
leaf observation-point {
type string;
description
"Capture point: ingress interface, mirror port, or sensor location.";
}
leaf topology-desc {
type string;
description
"Brief network topology description.";
}
leaf data-source-type {
type enumeration {
enum pcap;
enum flow;
enum session;
enum log;
enum payload;
}
description
"Underlying data format of the sample.";
}
}
¶
The attack-context grouping describes attack behavior, attack path, lifecycle, and tactics.¶
grouping attack-context {
leaf attack-path {
type string;
description
"Full attack path, e.g., attacker -> target -> lateral -> C2 -> exfiltration.";
}
leaf attack-category {
type enumeration {
enum reconnaissance;
enum brute-force;
enum dos;
enum exploitation;
enum malware;
enum c2;
enum tunneling;
enum data-exfiltration;
}
description
"High-level attack category.";
}
leaf attack-technique {
type string;
description
"MITRE ATT&CK technique identifier (optional).";
}
leaf attack-stage {
type enumeration {
enum reconnaissance;
enum exploitation;
enum persistence;
enum c2;
enum exfiltration;
}
description
"Attack lifecycle stage.";
}
leaf attack-intent {
type enumeration {
enum disruption;
enum info-disclosure;
enum privilege-escalation;
enum data-theft;
}
description
"Intended goal of the attack.";
}
leaf targeted-cve {
type string;
description
"Targeted CVE identifier if applicable.";
}
leaf affected-service {
type string;
description
"Affected protocol or service.";
}
}
¶
The data-content grouping describes what network data is included in the attack sample.¶
grouping data-content {
leaf packet-included {
type boolean;
description
"Whether full packet data is included.";
}
leaf flow-included {
type boolean;
description
"Whether flow records (IPFIX-compatible) are included.";
}
leaf payload-included {
type boolean;
description
"Whether application-layer payloads are included.";
}
leaf flow-count {
type uint32;
description
"Total number of flow records in the sample.";
}
leaf packet-count {
type uint64;
description
"Total number of packets in the sample.";
}
leaf duration {
type yang:timedelta;
description
"Total time duration covered by the sample.";
}
leaf-list flow-attributes {
type string;
description
"List of flow attributes included (e.g., 5-tuple, packet-count, flags).";
}
}
¶
The reproducibility-context grouping describes the information needed to replay, regenerate, validate, or compare a sample in an operational test or incident-analysis workflow.¶
grouping reproducibility-context {
leaf dataset-version {
type string;
description
"Version of the dataset or corpus that contains this sample.";
}
leaf generation-tool {
type string;
description
"Tool, generator, replay system, or collector used to produce the sample.";
}
leaf generation-parameters {
type string;
description
"Parameters used to generate or replay the sample. Sensitive values
SHOULD be omitted, redacted, or referenced through controlled access.";
}
leaf sanitization-method {
type string;
description
"Anonymization, minimization, or sanitization method applied to the sample.";
}
leaf validation-reference {
type string;
description
"Reference to validation results, detection-rule evaluation, or incident-analysis output.";
}
}
¶
A complete attack sample combines all five groupings:¶
grouping attack-sample {
uses sample-metadata;
uses collection-context;
uses attack-context;
uses data-content;
uses reproducibility-context;
description
"Top-level grouping that represents a full network attack sample.";
}
¶
file "ietf-attack-sample@2026-05-15.yang" module ietf-attack-sample { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-attack-sample"; prefix attack-sample;¶
import ietf-yang-types {
prefix yang;
reference "RFC 6991: YANG Common Data Types";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: https://datatracker.ietf.org/wg/opsawg/";
description
"This module defines a data model for describing network attack
samples with operational context, including collection context,
attack characteristics, data-content summary, and reproducibility
information.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, conditional upon the
compliance with IETF Trust Provisions and disclaimers.
This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices.";
revision 2026-05-15 {
description "Initial version";
reference "RFC XXXX: A YANG Data Model for Network Attack Sample Metadata";
}
grouping sample-metadata {
description
"Identification and management information for an attack sample.";
leaf sample-id {
type string;
description
"Unique identifier for the sample. A UUID is RECOMMENDED.";
}
leaf sample-version {
type string;
description
"Version identifier of the sample.";
}
leaf sample-name {
type string;
description
"Human-readable name of the sample.";
}
leaf description {
type string;
description
"Detailed description of the attack scenario.";
}
leaf creator {
type string;
description
"Creator or organization that produced the sample.";
}
leaf creation-time {
type yang:date-and-time;
description
"Time when the sample metadata was created.";
}
leaf usage-scope {
type enumeration {
enum training;
enum testing;
enum analysis;
enum rule-verification;
enum research;
enum incident-evidence;
}
description
"Intended operational usage of the sample.";
}
leaf anonymization {
type enumeration {
enum none;
enum partial;
enum full;
}
description
"Level of anonymization applied to the sample.";
}
}
grouping collection-context {
description
"Information describing when, where, and by which device the
sample was collected.";
leaf collection-start-time {
type yang:date-and-time;
description
"Start time of the data collection interval.";
}
leaf collection-end-time {
type yang:date-and-time;
description
"End time of the data collection interval.";
}
leaf collecting-device-type {
type enumeration {
enum router;
enum switch;
enum firewall;
enum probe;
enum host;
enum controller;
}
description
"Type of device that collected the traffic or telemetry.";
}
leaf device-vendor {
type string;
description
"Vendor of the collecting device.";
}
leaf device-model {
type string;
description
"Hardware model of the collecting device.";
}
leaf os-version {
type string;
description
"Operating system or firmware version.";
}
leaf observation-point {
type string;
description
"Capture point, such as an ingress interface, mirror port, or
sensor location.";
}
leaf topology-desc {
type string;
description
"Brief network topology description.";
}
leaf-list data-source-type {
type enumeration {
enum pcap;
enum flow;
enum session;
enum log;
enum payload;
}
description
"Underlying data formats represented by the sample.";
}
}
grouping attack-context {
description
"Information describing the observed attack behavior.";
leaf attack-path {
type string;
description
"Observed or inferred attack path.";
}
leaf attack-category {
type enumeration {
enum reconnaissance;
enum brute-force;
enum dos;
enum exploitation;
enum malware;
enum c2;
enum tunneling;
enum data-exfiltration;
enum other;
}
description
"High-level attack category.";
}
leaf attack-technique {
type string;
description
"External taxonomy identifier, if applicable.";
}
leaf attack-stage {
type enumeration {
enum reconnaissance;
enum exploitation;
enum persistence;
enum c2;
enum exfiltration;
enum mitigation;
enum unknown;
}
description
"Observed lifecycle stage.";
}
leaf attack-intent {
type enumeration {
enum disruption;
enum info-disclosure;
enum privilege-escalation;
enum data-theft;
enum unknown;
}
description
"Inferred intent of the observed behavior.";
}
leaf targeted-cve {
type string;
description
"Targeted CVE identifier, if applicable.";
}
leaf affected-service {
type string;
description
"Affected protocol, application, or network service.";
}
}
grouping data-content {
description
"Summary of the network data included in or referenced by the sample.";
leaf packet-included {
type boolean;
description
"Whether full packet data is included.";
}
leaf flow-included {
type boolean;
description
"Whether flow records are included.";
}
leaf payload-included {
type boolean;
description
"Whether application-layer payloads are included.";
}
leaf flow-count {
type uint32;
description
"Total number of flow records in the sample.";
}
leaf packet-count {
type uint64;
description
"Total number of packets in the sample.";
}
leaf duration {
type string;
description
"Total time duration covered by the sample.";
}
leaf-list flow-attributes {
type string;
description
"List of flow attributes included, such as 5-tuple,
packet-count, or flags.";
}
}
grouping reproducibility-context {
description
"Information needed to replay, regenerate, validate, or compare
the sample.";
leaf dataset-version {
type string;
description
"Version of the dataset or corpus that contains this sample.";
}
leaf generation-tool {
type string;
description
"Tool, generator, replay system, or collector used to produce the sample.";
}
leaf generation-parameters {
type string;
description
"Parameters used to generate or replay the sample.";
}
leaf sanitization-method {
type string;
description
"Anonymization, minimization, or sanitization method applied to the sample.";
}
leaf validation-reference {
type string;
description
"Reference to validation results, detection-rule evaluation, or
incident-analysis output.";
}
}
grouping attack-sample {
description
"Complete attack sample metadata.";
uses sample-metadata;
uses collection-context;
uses attack-context;
uses data-content;
uses reproducibility-context;
}
container attack-samples {
config false;
description
"Top-level container for network attack samples.";
list attack-sample {
key "sample-id";
description
"A single, fully contextualized network attack sample.";
uses attack-sample;
}
} }
¶
Operators may collect packet captures, IPFIX records, session logs, controller events, and mitigation logs from different observation points during an attack. These artifacts are often stored together as an operational data package, but the attack-specific meaning of the package is not always machine-readable. The model defined in this document can describe the sample identity, collection context, attack category, data content, anonymization status, and reproducibility information associated with those artifacts. This allows a collected data manifest to describe the package as a whole, while this model describes the attack sample contained in or referenced by that package.¶
When an enterprise network suffers from a large-scale DDoS attack, it may need to share selected attack characteristics with an upstream provider or mitigation service. In such scenarios, sending raw traffic is often impractical or undesirable because of volume, privacy, and operational sensitivity. The attack sample model defined in this document provides a compact and interoperable description of attack characteristics, including attack category, traffic distribution, packet or flow features, observation point, affected service, and anonymization status. This allows the receiving operator to understand the relevant evidence and formulate mitigation actions, while minimizing unnecessary exposure of raw data.¶
Operators and vendors often need to validate detection, filtering, traffic-cleaning, flow-analysis, and reporting tools against known attack samples. Without common sample metadata, two tools can process the same packet capture or flow set but interpret the collection point, label, time interval, anonymization level, or expected behavior differently. The model defined in this document enables repeatable testing and comparison by carrying the operational context and reproduction information with the sample.¶
Operators, vendors, and researchers maintain datasets for ML training, rule validation, regression testing, and operational readiness exercises. Such datasets are difficult to reuse when labels, collection parameters, sanitization methods, and validation results are not represented consistently. The model defined in this document provides metadata that can travel with a dataset or be referenced from a collected data manifest. This makes samples easier to index, compare, reproduce, and safely exchange.¶
This document includes no request to IANA.¶
This YANG data model defines structured descriptions of network attack samples, including attack behavior, traffic characteristics, payload fingerprints, collection context, and reproduction parameters. Sensitive information in this model requires careful security controls to prevent misuse, unauthorized access, or exposure to malicious parties.¶
Attack samples described by this model may contain highly sensitive information: * Exact attack methods, tools, and commands that could be reused for malicious activity * Network topology, device types, and deployment details of production environments * Payloads, fingerprints, and IoCs that reveal defense mechanisms * Labeled data that discloses internal detection rules and policies Unauthorized disclosure of such data could enable adversaries to improve attacks, evade defenses, or target specific network environments.¶
All read and query operations to the attack-sample data model MUST be restricted through strong authentication and authorization mechanisms. Implementations MUST use secure management protocols such as: * NETCONF over SSH (RFC 6241, RFC 6242) * RESTCONF over TLS 1.3 (RFC 8040, RFC 8446) Access control MUST follow the principle of least privilege. The Network Configuration Access Control Model (NACM, RFC 8341) SHOULD be used to restrict access to the attack-samples container and related components.¶
Thanks to Mingzhe Xing for his contribution to this draft.¶