]> Zhongguancun Laboratory

Beijing 100094 China lilz@zgclab.edu.cn

Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

OPS Operations and Management Area Working Group Network Attack Sample Metadata Operational Data Collected Data YANG 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.

Introduction 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 defines export of flow information. IODEF describes incident objects. The Collected Data Manifest describes metadata for collected operational data packages. NMOP work on network anomaly semantics and network incident management 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.

Relationship to OPSAWG and Existing Data Models 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.

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 BCP 14 RFC2119 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.

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

Architecture Diagram 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 ]]>

Component Relationships

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

Interoperability with Existing Standards

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

Attack Sample Module This section defines the core logical data model for Network Attack Sample Description in accordance with YANG 1.1 RFC7950. The model is modular, reusable, and compatible with IPFIX , the Collected Data Manifest , IODEF , 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

sample-metadata The sample-metadata grouping provides unique identification and management information for an attack sample. ## collection-context The collection-context grouping describes when, where, and by which device the attack sample was collected.

attack-context The attack-context grouping describes attack behavior, attack path, lifecycle, and tactics. 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."; } } ]]>

data-content The data-content grouping describes what network data is included in the attack sample.

reproducibility-context The reproducibility-context grouping describes the information needed to replay, regenerate, validate, or compare a sample in an operational test or incident-analysis workflow.

Top-Level Structure A complete attack sample combines all five groupings:

YANG Data Module 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;

Use Cases

Collected Attack Data Packages 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.

Cross-Domain DDoS Analysis 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.

Tool Validation and Regression Testing 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.

Operational Dataset Management 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.

IANA Considerations This document includes no request to IANA.

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

Sensitivity of Attack Sample Data 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.

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. Informative References This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). Everything OPS Huawei Telefonica I+D Telefonica I+D Swisscom Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. Swisscom Swisscom INSA-Lyon Huawei This document explains the motivation for defining semantic metadata annotations to help testing, validating and comparing Outlier and Symptom detection systems. These semantic annotations can be supported by supervised and semi-supervised machine learning algorithms and enable data exchange among network operators, vendors and academia, making anomalies apprehensible for humans. The proposed semantics uniforms the network anomaly data exchange between operators and vendors to improve their Service Disruption Detection Systems. CMCC Telefonica Huawei Ciena This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable cause analysis.

Acknowledgements Thanks to Mingzhe Xing for his contribution to this draft.