Skip to main content

A YANG Data Model for Network Attack Sample Metadata
draft-li-opsawg-attack-sample-metadata-00

Document Type Active Internet-Draft (individual)
Authors Linzhe Li , Yong Cui
Last updated 2026-06-17
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-li-opsawg-attack-sample-metadata-00
Operations and Management Area Working Group                       L. Li
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Standards Track                                  Y. Cui
Expires: 20 December 2026                            Tsinghua University
                                                            18 June 2026

          A YANG Data Model for Network Attack Sample Metadata
               draft-li-opsawg-attack-sample-metadata-00

Abstract

   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.

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 20 December 2026.

Li & Cui                Expires 20 December 2026                [Page 1]
Internet-Draft                    NASM                         June 2026

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
   2.  Relationship to OPSAWG and Existing Data Models . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Architecture Diagram  . . . . . . . . . . . . . . . . . .   5
     4.2.  Component Relationships . . . . . . . . . . . . . . . . .   6
     4.3.  Interoperability with Existing Standards  . . . . . . . .   7
   5.  Attack Sample Module  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  sample-metadata . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  attack-context  . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  data-content  . . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  reproducibility-context . . . . . . . . . . . . . . . . .  12
     5.5.  Top-Level Structure . . . . . . . . . . . . . . . . . . .  13
   6.  YANG Data Module  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Collected Attack Data Packages  . . . . . . . . . . . . .  20
     7.2.  Cross-Domain DDoS Analysis  . . . . . . . . . . . . . . .  20
     7.3.  Tool Validation and Regression Testing  . . . . . . . . .  21
     7.4.  Operational Dataset Management  . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     9.1.  Sensitivity of Attack Sample Data . . . . . . . . . . . .  22
     9.2.  Access Control  . . . . . . . . . . . . . . . . . . . . .  22
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

Li & Cui                Expires 20 December 2026                [Page 2]
Internet-Draft                    NASM                         June 2026

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

Li & Cui                Expires 20 December 2026                [Page 3]
Internet-Draft                    NASM                         June 2026

   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.

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

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

Li & Cui                Expires 20 December 2026                [Page 4]
Internet-Draft                    NASM                         June 2026

   Operational Attack Sample: An attack sample used for operational
   analysis, mitigation validation, data-set management, or evidence
   exchange.

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

4.1.  Architecture Diagram

Li & Cui                Expires 20 December 2026                [Page 5]
Internet-Draft                    NASM                         June 2026

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

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

Li & Cui                Expires 20 December 2026                [Page 6]
Internet-Draft                    NASM                         June 2026

   *  Data Content is the raw network evidence (packet/flow/session).

   *  Reproducibility information ensures the sample can be regenerated
      for verification.

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

5.  Attack Sample Module

   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

5.1.  sample-metadata

   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;

Li & Cui                Expires 20 December 2026                [Page 7]
Internet-Draft                    NASM                         June 2026

    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.

Li & Cui                Expires 20 December 2026                [Page 8]
Internet-Draft                    NASM                         June 2026

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.";
  }

Li & Cui                Expires 20 December 2026                [Page 9]
Internet-Draft                    NASM                         June 2026

  leaf data-source-type {
    type enumeration {
      enum pcap;
      enum flow;
      enum session;
      enum log;
      enum payload;
    }
    description
      "Underlying data format of the sample.";
  }
}

5.2.  attack-context

   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;

Li & Cui                Expires 20 December 2026               [Page 10]
Internet-Draft                    NASM                         June 2026

      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.";
  }
}

5.3.  data-content

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

Li & Cui                Expires 20 December 2026               [Page 11]
Internet-Draft                    NASM                         June 2026

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).";
  }
}

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

Li & Cui                Expires 20 December 2026               [Page 12]
Internet-Draft                    NASM                         June 2026

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.";
  }
}

5.5.  Top-Level Structure

   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.";
 }

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

Li & Cui                Expires 20 December 2026               [Page 13]
Internet-Draft                    NASM                         June 2026

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.";
  }

Li & Cui                Expires 20 December 2026               [Page 14]
Internet-Draft                    NASM                         June 2026

  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 {

Li & Cui                Expires 20 December 2026               [Page 15]
Internet-Draft                    NASM                         June 2026

    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;

Li & Cui                Expires 20 December 2026               [Page 16]
Internet-Draft                    NASM                         June 2026

      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.";
  }

Li & Cui                Expires 20 December 2026               [Page 17]
Internet-Draft                    NASM                         June 2026

  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;

Li & Cui                Expires 20 December 2026               [Page 18]
Internet-Draft                    NASM                         June 2026

    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.";
  }
}

Li & Cui                Expires 20 December 2026               [Page 19]
Internet-Draft                    NASM                         June 2026

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;
  }
}   }

7.  Use Cases

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

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

Li & Cui                Expires 20 December 2026               [Page 20]
Internet-Draft                    NASM                         June 2026

   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.

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

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

8.  IANA Considerations

   This document includes no request to IANA.

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

Li & Cui                Expires 20 December 2026               [Page 21]
Internet-Draft                    NASM                         June 2026

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

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

10.  References

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6991>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7950>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/rfc/rfc8340>.

10.2.  Informative References

Li & Cui                Expires 20 December 2026               [Page 22]
Internet-Draft                    NASM                         June 2026

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/rfc/rfc7011>.

   [RFC7970]  Danyliw, R., "The Incident Object Description Exchange
              Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
              November 2016, <https://www.rfc-editor.org/rfc/rfc7970>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/rfc/rfc8341>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8040>.

   [I-D.ietf-opsawg-collected-data-manifest]
              Claise, B., Quilbeuf, J., Lopez, D., Martinez-Casanueva,
              I. D., and T. Graf, "A Data Manifest for Contextualized
              Telemetry Data", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-collected-data-manifest-10, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              collected-data-manifest-10>.

   [I-D.ietf-nmop-network-anomaly-semantics]
              Graf, T., Du, W., Feng, A. H., and V. Riccobene, "Semantic
              Metadata Annotation for Network Anomaly Detection", Work
              in Progress, Internet-Draft, draft-ietf-nmop-network-
              anomaly-semantics-05, 19 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-anomaly-semantics-05>.

   [I-D.ietf-nmop-network-incident-yang]
              Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
              "A YANG Data Model for Network Incident Management", Work
              in Progress, Internet-Draft, draft-ietf-nmop-network-
              incident-yang-08, 13 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-incident-yang-08>.

Li & Cui                Expires 20 December 2026               [Page 23]
Internet-Draft                    NASM                         June 2026

Acknowledgements

   Thanks to Mingzhe Xing for his contribution to this draft.

Authors' Addresses

   Linzhe Li
   Zhongguancun Laboratory
   Beijing
   100094
   China
   Email: lilz@zgclab.edu.cn

   Yong Cui
   Tsinghua University
   Beijing, 100084
   China
   Email: cuiyong@tsinghua.edu.cn
   URI:   http://www.cuiyong.net/

Li & Cui                Expires 20 December 2026               [Page 24]