6man X. Gu, Ed. Internet-Draft N. Zhang, Ed. Intended status: Standards Track X. Yi, Ed. Expires: 11 June 2026 China Unicom 8 December 2025 A whitelist-based data fencing mechanism in data circulation draft-gu-6man-whitelist-data-circulation-00 Abstract This document defines the data transaction permission fields within the Data Fencing architecture and the whitelist information maintained by the gateway devices. By comparing the data transaction permission fields against the whitelist, data packets are either permitted or blocked, establishing precise data flow boundaries and egress control. Finally, the document presents several use cases of the data fencing. 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 11 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Gu, et al. Expires 11 June 2026 [Page 1] Internet-Draft A whitelist-based data fencing mechanism December 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Data Fencing . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Data Fencing Architecture . . . . . . . . . . . . . . . . 4 3.2. Data Transaction Permission Attribute TLV . . . . . . . . 5 3.3. Whitelist . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Implementation Process of the Data Fencing Function . . . . . 7 4.1. Information Registration of Data Transaction Parties . . 7 4.2. Data Transaction Process . . . . . . . . . . . . . . . . 8 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Cross-Domain Data Cooperation and Development . . . . . . 9 5.2. Data Sharing and Isolation in Multi-Cloud Environments . 10 5.3. Secure Data Acquisition and Boundary Control in IoT Environments . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Amidst the accelerating wave of digital transformation, data has undeniably emerged as a core factor of production, whose value can only be maximized through sufficient circulation, sharing, and integration. However, this very flow and sharing of data introduce formidable challenges to security and privacy preservation. Traditional data access control mechanisms, such as firewalls, Virtual Private Networks (VPNs), and Role-Based Access Control (RBAC), have played significant roles in static, well-defined network environments. Yet, in complex scenarios like cross-domain data exchange, multi-cloud collaboration, and industrial chain coordination, data becomes susceptible to replication, download, and forwarding. Once data traverses traditional security boundaries, these static policies prove inadequate, failing to meet the demands of dynamic data flow. This inadequacy precipitates a sharp increase Gu, et al. Expires 11 June 2026 [Page 2] Internet-Draft A whitelist-based data fencing mechanism December 2025 in risks, including data misuse, unauthorized dissemination, and insider threats. In this context, Data Fencing has emerged as a novel paradigm for data security. It moves beyond reliance on fixed network perimeters by deeply integrating security policies with the data itself, thereby establishing a dynamic, mandatory security boundary that persists throughout the entire data lifecycle. The core principle of Data Fencing lies in employing policy definitions and technical measures to enforce granular control and restrictions over data access, transmission, and usage scope. This ensures that sensitive data remains protected from access or leakage by unauthorized users or systems. Within this architecture, the gateway device assumes a critical role as the policy enforcement point. By dynamically maintaining whitelists, it constructs granular boundaries for data flow. This mechanism ensures that data moves securely within authorized confines, effectively guarding against unauthorized access and insider threats. Consequently, it upholds data security, integrity, and compliance while enhancing fine-grained governance capabilities within the data space. This document defines the data transaction permission fields within the Data Fencing architecture and the whitelist information maintained by the gateway devices. By comparing the data transaction permission fields against the whitelist, data packets are either permitted or blocked, establishing precise data flow boundaries and egress control. Finally, the document presents several use cases of the data fencing. 2. Conventions and Definitions 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. Abbreviations and definitions used in this document: *HBH: Hop-by-Hop Options Header. 3. Data Fencing Gu, et al. Expires 11 June 2026 [Page 3] Internet-Draft A whitelist-based data fencing mechanism December 2025 3.1. Data Fencing Architecture In the data fencing architecture, the primary components include the Data Circulation and Utilization Platform, the Network Management Platform, Gateway Devices, and Access Devices. Access devices are connected to their respective gateway device, and different access devices can transmit data via links between gateway deivices. Figure 1 shows the data fencing architecture. +-----------------------------------------------------------------------------------------+ | Data Circulation and Utilization Platform | +-----------------------------------------------------------------------------------------+ | | | | +-----------------------------------------------------------------------------------------+ | Network Management Platform | +-----------------------------------------------------------------------------------------+ | | | | | | | | | | +-------------+ +-----------+ | | | Gateway | | Access | | | | |-------| | | | | Device 1 | | Device 1 | | | +-------------+ +-----------+ | | / \ | | / \ | | / \ | +-----------+ +-------------+ +-------------+ +-----------+ | Access | | Gateway | | Gateway | | Access | | |-----| | | |-------| | | Device 3 | | Device 3 | | Device 2 | | Device 2 | +-----------+ +-------------+ +-------------+ +-----------+ Figure 1: The data fencing architecture The Data Circulation and Utilization Platform serves as a centralized marketplace that facilitates data transactions between data providers and consumers, aiming to break down data silos and promote seamless data exchange and sharing. In scenarios where certain users engage in frequent data transactions and seek to establish long-term, stable data sharing relationships, the platform offers specialized services through "Data Transaction Groups." Members within a Data Transaction Group are mutually trusted regarding data circulated inside the group, enabling secure and efficient collaboration. Each Data Gu, et al. Expires 11 June 2026 [Page 4] Internet-Draft A whitelist-based data fencing mechanism December 2025 Transaction Group is assigned a unique identifier for management and recognition.The Data Circulation and Utilization Platform sends Data Transaction Group information to the Network Management Platform. The Network Management Platform is responsible for the flexible orchestration and scheduling of network resources. It supports the deployment of policies to network devices, enabling on-demand isolation and connection of access nodes as required. Additionally, this platform manages the unified allocation and administration of network identifiers, ensuring orderly and controlled network operations.The Network Management Platform deliver the Data Transaction Group information to the corresponding gateway devices. The gateway device, serving as the network entry point, is capable of receiving IPv6 packets from data access endpoints. It maintains a dynamic whitelist in real-time, which constitutes a collection of authorized data group identifiers permitted for transmission. For a specific data circulation instance, consider User 1 and User 2 as the authorized parties in the data transaction, while User 3 is not authorized. When data is being transmitted between User 1 and User 2, if the direct link between them experiences issues such as interruption or congestion, data packets may be rerouted along an alternative path, for example: User 1 -> User 3 -> User 2. Since User 3 is not authorized to access the data, it is imperative to prevent User 3 from gaining any visibility or access to the data packets during this process. 3.2. Data Transaction Permission Attribute TLV The Data Transaction Permission Attribute can be directly encapsulated as an option in IPv6 extension headers within Hop-by-Hop Options Header(HBH) [RFC8200]. It's a newly defined TLV used to to indicate whether the gateway device is permitted to forward the IPv6 packet. Figure 2 shows the Data Permission Attribute TLV 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 |D| Unassigned | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data Transaction Group ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gu, et al. Expires 11 June 2026 [Page 5] Internet-Draft A whitelist-based data fencing mechanism December 2025 Figure 2: Data Permission Attribute TLV format * Type: 8-bit identifier. * Length: 8-bit unsigned integer that indicates the total number of the octets of the value field. * D: 1-bit field used to indicate whether the current data transaction is directed. * Unassigned: 15-bit field reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt. * Data Transaction Group ID: 64-bit group ID of Data Transaction Group. The Data Transaction Group ID is used to store the data transaction group to which the data belongs. Under normal circumstances, every member within a data trading group is considered trustworthy for data circulated inside the group. The D field is used to indicate whether the current data transaction is directed. This field supports two values: 0 and 1. When the field is set to 0, it means disabling directed data transaction, representing a standard data transaction where all members within the data transaction group are considered trustworthy and may access the group's data. When the field is set to 1, it means enabling directed data transaction, representing a directed data transaction where the data is only accessible to specific designated users within the data transaction group. The information of these authorized users is delivered by the Network Management Platform to the relevant gateway devices for enforcement. 3.3. Whitelist The gateway device maintains a whitelist of connected data access devices. This whitelist records information about devices or users permitted to access data through the gateway device. It contains two types of information: a Data Transaction Group ID and an Enable/ Disable Directed Data Transaction flag. These two types of information are updated after the gateway device receives instructions issued by the Network Management Platform. The main scenarios are as follows: Gu, et al. Expires 11 June 2026 [Page 6] Internet-Draft A whitelist-based data fencing mechanism December 2025 1. Data Transaction Group ID Update Updates to the Data Transaction Group ID generally occur when new users join the Data Circulation and Utilization Platform. If a new user wishes to join one or more existing data transaction groups, the gateway device used by that new user will add the corresponding Data Transaction Group ID(s) to its whitelist.If a new user intends to establish one or more new data transaction groups, the Network Management Platform will notify all members within the group. Each member's gateway device will then add the ID of the new data transaction group to its respective whitelist. 1. Enable/Disable Directed Data Transaction Update Updates to the Enable/Disable Directed Data Transaction flag(D field) generally occur during directed data transactions.By default, directed data transactions are disabled. When a directed data transaction is initiated, the initiator informs the Data Circulation and Utilization Platform of the intended participants. The Network Management Platform then notifies the gateway devices of the corresponding users, and these gateway devices set the D field to 1.Upon completion of the data transaction, the Network Management Platform again notifies the relevant gateway devices, which reset the D field to 0. The gateway device can identify the information in each field of the network identifier. By comparing the Data Transaction Permission Attribute with the whitelist-stored information on permitted data groups, a determination is made regarding whether to discard the data packet, which means the gateway device conditionally allows or blocks data transmission. In the event of data being blocked, the gateway device reports a warning to the Network Management Platform, indicating a case of non-compliant data flow, thereby facilitating timely adjustment of data circulation paths and strategies. 4. Implementation Process of the Data Fencing Function 4.1. Information Registration of Data Transaction Parties Upon initial access to the Data Circulation and Utilization Platform, users register by submitting their profile information, including specifications of the data trading groups they intend to join or establish.The Data Circulation and Utilization Platform updates the Data Transaction Group Information Table: If the user wishes to join one or more existing data transaction groups, the platform adds the user to the corresponding data trading group and updates the member information of the corresponding group(s). If the user wishes to establish one or more new data transaction groups, the platform creates the corresponding data trading group and updates the Gu, et al. Expires 11 June 2026 [Page 7] Internet-Draft A whitelist-based data fencing mechanism December 2025 information of the new group(s), including assigning a unique identifier to the new group and recording the member information within the new group. Then, the Data Circulation and Utilization Platform distributes the Data Transaction Group Information Table to the Network Management Platform via a synchronization interface. Upon receiving messages from the Data Circulation Platform, the Network Management Platform distributes the Data Trading Group Information Table to gateway devices. If the user wishes to join an existing data trading group, the Network Management Platform delivers the identifier of the target data trading group to the user's gateway device.If the user wishes to establish a new data trading group, the Network Management Platform delivers the new group information to the gateway device of all members (including the requesting user). The relevant gateway devices update their whitelists accordingly. 4.2. Data Transaction Process Steps for Implementing Data Fencing via Whitelist on Gateway Devices for a Single Data Transaction The access device on the provider side adds a Data Transaction Permission attribute to the data packet. This attribute carries information about the transaction, including the Data Transaction Group ID and whether it is a Directed Data Transaction. The packet is then sent to the provider's gateway device. The gateway device on the data provider side forwards data packets to the corresponding network path based on policies delivered by the Network Management Platform. Each gateway device along the transmission path inspects the Data Transaction Permission attribute and makes a forwarding decision as follows:The gateway device checks the Data Transaction Group ID field.If the group ID is not in the gateway's whitelist, the packet is blocked (discarded).If the group ID is in the whitelist, the gateway device proceeds to inspect the D field.The gateway device then checks the D field:If the value is 0 (standard transaction), the packet is allowed.If the value is 1 (directed transaction), the gateway device checks whether directed transmission is enabled locally:If enabled -> the packet is allowed.If not enabled -> the packet is blocked (discarded). If a gateway device blocks a packet, it reports a warning message to the Network Management Platform, including the device ID and relevant information about the discarded packet. 5. Use Cases Gu, et al. Expires 11 June 2026 [Page 8] Internet-Draft A whitelist-based data fencing mechanism December 2025 5.1. Cross-Domain Data Cooperation and Development Data is increasingly becoming a core factor of production that drives innovation and growth. Individual organizations often face limitations in their internal data and capabilities, making it difficult to tackle complex development challenges or seize market opportunities alone. Therefore, it is necessary to integrate complementary data resources, specialized knowledge, and technical expertise from different institutions such as enterprises and research institutes. Through cross-domain data collaboration and development, organizations can break down information silos, leverage complementary strengths, and achieve mutual benefits through cooperation. In cross-domain scenarios, it is essential to ensure that sensitive data shared between parties is used only for specific projects, by specific personnel, and within specific boundaries, preventing data from being copied, retained, or utilized for unauthorized purposes. Data fencing can establish a dynamic, mandatory security boundary that accompanies the data throughout its entire lifecycle. Its key functions include: 1. Establishing a Dynamic and Trusted Access Boundary: Only devices that are formally registered and authorized for participation in the project are included in the whitelist for data access. This ensures that data can only be accessed by predefined, trusted devices and users, effectively preventing unauthorized access at the point of entry. 2. Providing Real-Time Violation Alerting and Response Capabilities: Data fencing acts not only as a protective shield for data but also as an active defense system with monitoring and response capabilities. Leveraging data fencing functionality, when a gateway device detects non-compliant behavior such as unauthorized access or operation attempts, it can immediately report an alert to the management platform. The alert may include detailed information such as the identity of the violator, the time of the incident, and the specific nature of the violation. This shifts security protection from post-event analysis to real-time blocking and alerting during incidents, effectively guarding against both internal risks and external infiltration attempts. Gu, et al. Expires 11 June 2026 [Page 9] Internet-Draft A whitelist-based data fencing mechanism December 2025 5.2. Data Sharing and Isolation in Multi-Cloud Environments Amid the wave of enterprise digital transformation, companies often adopt hybrid or multi-cloud architectures to optimize costs and leverage the unique advantages of different cloud service providers. As a result, business data naturally resides across diverse cloud platforms. For instance, core transaction data may be stored in a private cloud, while data requiring large-scale computational analysis is deployed in a public cloud. At the same time, cross- departmental collaboration and industrial chain coordination require data to flow securely within authorized boundaries. This demand for data sharing must be balanced against stringent data security and compliance requirements. Sensitive data, such as user personal information, financial records, and trade secrets, must be strictly isolated to prevent unauthorized access and data leaks, thereby meeting increasingly rigorous data protection regulations. Data fencing addresses these challenges by establishing intelligent, policy-driven micro-boundaries around the data itself, ensuring secure and seamless data flow within authorized limits, even in complex multi-cloud environments. 1. Fine-Grained Data-Level Isolation and Policy Attachment: In hybrid cloud environments, data fencing moves beyond reliance on physical or network perimeters by directly binding security policies to data assets. This enables precise isolation of data with varying sensitivity levels even within the same database or the same table. 2. Unified Security Management to Reduce Multi-Cloud Complexity: Data fencing provides a unified security management plane, offering enterprises a holistic view and centralized control over data flows across clouds. This significantly simplifies the implementation of consistent security and compliance policies within heterogeneous IT environments. 5.3. Secure Data Acquisition and Boundary Control in IoT Environments As production lines deploy a vast number of heterogeneous sensors and devices, massive volumes of equipment status, operational parameters, and production data are generated in real time. This data not only serves as a core asset for enabling predictive maintenance, process optimization, and intelligent decision-making but also constitutes business-critical information directly tied to production continuity and product quality. However, the inherent characteristics of IoT environments resource-constrained terminal devices, diverse communication protocols, and blurred network boundaries expose them to multiple security threats. These include unauthorized device Gu, et al. Expires 11 June 2026 [Page 10] Internet-Draft A whitelist-based data fencing mechanism December 2025 access, data tampering or theft during transmission, and the leakage of sensitive production data to unauthorized systems. Data fencing establishes a micro-security fortress for IoT environments through identity authentication, integrity verification, and strict egress policies. This ensures that every piece of data flowing into the enterprise's digital core is trustworthy, intact, and controlled, laying a solid security foundation for truly intelligent industrial production. 1. Establishing a Trusted Identity Boundary and Access Control:Data fencing implements a strict whitelist mechanism at the collection gateway device (device gateway). The unique identifiers (e.g., MAC addresses, digital certificates) of every legitimate sensor and device are pre-registered in the data fencing whitelist during factory setup or deployment. Any unauthorized device attempting to connect is identified and blocked at the connection stage, thereby ensuring the purity and trustworthiness of data sources. 2. Constructing Precise Data Flow Boundaries and Egress Control:Data fencing defines the only legitimate exit points for data at the IoT gateway device, strictly controlling where data can be transmitted. Collected data can only be sent to one or several designated and authorized central analysis platform IP addresses. Any attempt to copy or forward data to unauthorized IP addresses is blocked in real time, preventing illegal data replication and leakage while ensuring that operational data remains within the enterprise's authorized scope of control. 6. Security Considerations TBD 7. IANA Considerations TBD 8. References 8.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, . Gu, et al. Expires 11 June 2026 [Page 11] Internet-Draft A whitelist-based data fencing mechanism December 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Authors' Addresses Xinrui Gu (editor) China Unicom Beijing China Email: guxr12@chinaunicom.cn Naihan Zhang (editor) China Unicom Beijing China Email: zhangnh12@chinaunicom.cn Xinxin Yi (editor) China Unicom Beijing China Email: yixx3@chinaunicom.cn Gu, et al. Expires 11 June 2026 [Page 12]