SIDROPS L. Liu Internet-Draft Zhongguancun Laboratory Intended status: Standards Track Z. Yan Expires: 23 April 2026 CNNIC L. Chen Zhongguancun Laboratory D. Li Tsinghua University 20 October 2025 RPKI Repository Delta Protocol (RRDP) Delta File Retention Policy draft-liu-sidrops-rrdp-delta-retention-policy-00 Abstract This document updates RFC 8182 (The RPKI Repository Delta Protocol) by specifying an optimized delta file retention policy based on client access patterns. The proposed mechanism allows RRDP servers to maintain only the delta files required by active clients, reducing storage requirements while maintaining compatibility with existing clients. By tracking which serial numbers are being requested by active clients, the repository can determine the minimum serial number needed by any client and safely prune delta files that update from earlier serial numbers. The proposed mechanism provides several benefits, including reduced storage requirements, smaller notification files, and more efficient use of bandwidth and processing resources. It also maintains backward compatibility with existing RRDP clients, requiring no changes to client implementations. 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 23 April 2026. Liu, et al. Expires 23 April 2026 [Page 1] Internet-Draft RRDPDR October 2025 Copyright Notice Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Existing Delta File Retention Strategies . . . . . . . . 4 2.2. Challenges with Current Strategies . . . . . . . . . . . 4 3. Adaptive Delta File Retention Policy . . . . . . . . . . . . 5 3.1. Client Tracking Mechanism . . . . . . . . . . . . . . . . 5 3.2. Minimum Serial Number Determination . . . . . . . . . . . 6 3.3. Delta File Pruning Algorithm . . . . . . . . . . . . . . 7 3.4. Integration with Existing Size-based Retention Policy . . 8 4. Implementation Considerations . . . . . . . . . . . . . . . . 8 4.1. Server Implementation . . . . . . . . . . . . . . . . . . 9 4.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The RPKI Repository Delta Protocol (RRDP) [RFC8182] defines a mechanism for publishers to make available a set of current repository objects, and for relying parties to maintain a local copy of this repository that is periodically updated to match the published repository. RFC 8182 specifies that repository must maintain a set of delta files that allow relying parties to update from any recent state to the current state. It proposes a size-based delta file retention strategy, stating that "Any older Delta Files that, when combined with all more recent Delta Files, will result in the total size of Liu, et al. Expires 23 April 2026 [Page 2] Internet-Draft RRDPDR October 2025 deltas exceeding the size of the snapshot MUST be excluded to avoid that Relying Parties download more data than necessary.". However, as the number of existing RPKI objects grows and more are proposed, the snapshot file size increases significantly, requiring more delta files to be stored. This leads to higher storage costs and potential performance issues. Consequently, practical implementations have adopted various strategies to mitigate these issues, such as count- based limits (maintaining a fixed number of delta files) and time- based limits (retaining delta files only for a specified duration). This document updates RFC 8182 by defining an adaptive delta file retention policy based on client access patterns. The key insight is that repositories need only maintain delta files that might be used by active relying parties. By tracking the minimum serial number accessed by active clients, repositories can safely prune older delta files that are no longer needed, while ensuring that all active clients can still perform incremental updates. This adaptive approach can be integrated with existing size-based delta file retention strategy [RFC8182] to provide a more comprehensive solution. This approach provides several benefits: 1. Reduced storage requirements for RRDP servers; 2. Improved efficiency in delta file management; 3. Maintained backward compatibility with existing RRDP clients; 4. Potential performance improvements for notification file processing; 5. Better adaptation to actual client update patterns. 1.1. Requirements Language 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. 2. Background This section reviews existing delta file retention strategies and illustrates their potential limitations. Liu, et al. Expires 23 April 2026 [Page 3] Internet-Draft RRDPDR October 2025 2.1. Existing Delta File Retention Strategies Section 3.3.2 of RFC 8182 mandates that servers limit the number of deltas in the notification file such that the combined size of the underlying delta files does not exceed that of the snapshot file. Servers are free to further limit the number of deltas included in the notification file, though. Two common strategies are: 1. *Count-based retention*: Maintaining a fixed number of most recent delta files (e.g., the last 500 delta files). This approach is simple to implement but does not account for varying delta file sizes or client access patterns, and may lead to frequently downloading the full snapshot for clients. 2. *Time-based retention*: Keeping delta files for a specified time period (e.g., 2 hours). This approach ensures clients that update regularly can use delta files, but may not be optimal for clients with irregular update schedules and may also lead to frequently downloading the full snapshot for clients. These strategies are typically implemented as configuration options in RRDP server software, allowing repository operators to choose the approach that best fits their needs. 2.2. Challenges with Current Strategies While the existing retention strategies provide some guidance, they have several limitations: 1. *Size-based retention*: * Does not consider client access patterns; * Can lead to inefficient storage use if many small delta files are retained when they are no longer needed. This issue may be exacerbated when the snapshot size grows along with the number increasement of existing objects and the addition of more new objects. 2. *Count-based retention*: * Arbitrary fixed limits may not match actual client needs; * Does not adapt to changing repository update frequencies; * May discard delta files that are still needed by active clients. Liu, et al. Expires 23 April 2026 [Page 4] Internet-Draft RRDPDR October 2025 3. *Time-based retention*: * Does not account for varying client update frequencies and may retain too many files during periods of frequent updates or too few during periods of infrequent updates; * May retain files longer than necessary if no clients need them; * May discard delta files that are still needed by active clients. These challenges highlight the need for a more adaptive approach to delta file retention that considers actual client behavior while maintaining compatibility with existing client implementations. 3. Adaptive Delta File Retention Policy This document defines an adaptive delta file retention policy based on client access patterns. The key principle is that repositories need only maintain delta files that might be used by active relying parties. This approach would not like to replace the existing size- based retention strategy proposed in RFC 8182 and can be integrated with it to make RRDP work in a more efficient and adaptive manner. The policy consists of three main components: 1. A client tracking mechanism that records the serial numbers accessed by clients; 2. A method for determining the minimum serial number needed by active clients; 3. An algorithm for pruning delta files that are no longer needed. By implementing this policy, RRDP repositories can reduce storage requirements while ensuring that all active clients can perform incremental updates. 3.1. Client Tracking Mechanism To implement the adaptive delta file retention policy, RRDP repositories MUST track the serial numbers accessed by clients. This can be accomplished by monitoring client requests for delta files. Liu, et al. Expires 23 April 2026 [Page 5] Internet-Draft RRDPDR October 2025 When a client requests a delta file, it typically does so by first retrieving the notification file, identifying the appropriate delta file based on its current local serial number, and then requesting that specific delta file. Repositories SHOULD maintain a data structure that records: 1. Client identifiers (e.g., IP addresses or anonymized identifiers); 2. The serial numbers requested by each client; 3. Timestamps of the most recent requests. Figure 1 shows an example for the data structure to record RRDP clients. | Client ID | Serial Number | Last Access Time | |-----------|---------------|------------------------------| | Client A | 42 | July 10, 2025, at 12:00PM UTC| | Client B | 37 | July 11, 2025, at 08:30AM UTC| | Client C | 45 | July 11, 2025, at 14:15PM UTC| Figure 1: An example for the data structure to record RRDP clients. Repositories MAY implement more sophisticated tracking mechanisms, such as: * Using probabilistic data structures (e.g., Bloom filters) to efficiently track large numbers of clients; * Implementing privacy-preserving techniques to avoid storing identifiable client information. Repositories SHOULD periodically clean this data structure to remove entries for clients that have not been seen for a configurable period (e.g., 7 days). This helps ensure that the minimum serial number calculation is based only on active clients. 3.2. Minimum Serial Number Determination Based on the client tracking data, repositories can determine the minimum serial number needed by active clients. This is the smallest serial number that any active client might need to update from. The algorithm for determining the minimum serial number is as follows: Liu, et al. Expires 23 April 2026 [Page 6] Internet-Draft RRDPDR October 2025 1. Initialize min_serial to the current repository serial number; 2. For each active client in the tracking data: a. If the client's serial number is less than min_serial, update min_serial to the client's serial number; 3. Return min_serial. For example, using the client tracking data from the previous section: * Current repository serial number: 50; * Client A's serial number: 42; * Client B's serial number: 37; * Client C's serial number: 45; * Minimum serial number: 37. Repositories SHOULD recalculate the minimum serial number: * Whenever a new delta file is created; * Periodically (e.g., daily) to account for client tracking data cleanup; * Before any delta file pruning operation. Repositories MAY implement a safety margin by subtracting a small value from the calculated minimum serial number. This helps ensure that clients that have recently become active but have not yet requested a delta file can still perform incremental updates. 3.3. Delta File Pruning Algorithm Once the minimum serial number has been determined, repositories can safely prune delta files that are no longer needed. A delta file is no longer needed if it allows updating from a serial number that is less than the minimum serial number. The algorithm for delta file pruning is as follows: 1. Determine the minimum serial number (min_serial) as described in Section 3.2; Liu, et al. Expires 23 April 2026 [Page 7] Internet-Draft RRDPDR October 2025 2. For each delta file: a. Extract the "from" serial number (from_serial) from the delta file metadata; b. If from_serial < min_serial, mark the delta file for deletion; 3. Delete all marked delta files; 4. Update the notification file to remove references to the deleted delta files. For example, if the minimum serial number is 37, delta files that update from serial numbers 1-36 can be safely deleted. Repositories MAY implement the following safeguards: * Never delete the most recent N (e.g., 5) delta files, regardless of the minimum serial number calculation; * Maintain delta files for a minimum time period before considering them for deletion; * Implement a gradual pruning strategy to avoid sudden changes in available delta files. Publishers MUST ensure that after pruning, the notification file still contains at least one delta element, unless the current serial number is 1. 3.4. Integration with Existing Size-based Retention Policy The adaptive delta file retention policy described in this document MUST be integrated with the size-based retention policy specified in [RFC8182]. The integration SHOULD be implemented as follows: * First, determine the minimum set of delta files required by active clients using the adaptive policy; * Then, if the total size of these delta files exceeds the snapshot file size, remove older delta files to ensure the total size of retained delta files doe not exceed the size of the snapshot file, as required by [RFC8182]. 4. Implementation Considerations Liu, et al. Expires 23 April 2026 [Page 8] Internet-Draft RRDPDR October 2025 4.1. Server Implementation Repositories implementing the adaptive delta file retention policy SHOULD follow these guidelines: 1. Client Tracking: * Use efficient data structures for client tracking as described in Section 3.1; * Regularly clean up tracking data for inactive clients. 2. Configuration Options: * Allow configuration of the client inactivity threshold (default: 7 days); * Allow configuration of the safety margin for minimum serial number calculation (default: 5). 3. Operational Features: * Provide monitoring and alerting for delta file management; * Log delta file pruning operations; * Expose metrics on storage savings and client serial number distribution. 4. Fallback Mechanisms: * Implement mechanisms to recover if delta files are accidentally pruned too aggressively; * Consider maintaining an archive of pruned delta files that can be restored if needed. Repositories MAY implement the following optimizations: * Batch delta file pruning operations to reduce the frequency of notification file updates; * Implement predictive algorithms to anticipate client behavior and adjust the safety margin accordingly. Liu, et al. Expires 23 April 2026 [Page 9] Internet-Draft RRDPDR October 2025 4.2. Client Behavior No changes to client behavior are required to benefit from the adaptive delta file retention policy. Existing RRDP clients will continue to function as specified in RFC 8182. 5. Privacy Considerations The client tracking mechanism described in Section 3.1 involves collecting information about client behavior, which raises privacy concerns. Repositories implementing this mechanism SHOULD take steps to protect client privacy: 1. Anonymization: * Use anonymized identifiers instead of storing actual IP addresses; * Consider using techniques such as IP address hashing with a rotating salt; * Ensure that the anonymization method still allows tracking the same client across multiple requests. 2. Data Minimization: * Store only the minimum information needed (client identifier, serial number, timestamp); * Do not store additional information such as User-Agent strings or other HTTP headers unless necessary for debugging. 3. Data Retention: * Implement strict data retention policies; * Delete tracking data for clients that have not been seen for a configurable period (e.g., 7 days). Repositories MAY implement more sophisticated privacy-preserving techniques, such as differential privacy or secure multi-party computation, to further protect client privacy while still benefiting from the adaptive delta file retention policy. 6. Security Considerations The adaptive delta file retention policy introduces several security considerations: Liu, et al. Expires 23 April 2026 [Page 10] Internet-Draft RRDPDR October 2025 1. Denial of Service: * An attacker could potentially manipulate the minimum serial number calculation described in Section 3.2 by repeatedly requesting delta files with very old serial numbers * To mitigate this, repositories SHOULD: - Implement rate limiting for delta file requests; - Use anomaly detection to identify suspicious patterns; - Consider weighting client importance based on factors such as reputation or update frequency; - Implement the safeguards described in Section 3.3 to provide additional protection. 2. Information Leakage: * The client tracking mechanism could potentially leak information about client update patterns; * Repositories SHOULD implement the privacy considerations described in Section 5 to mitigate this risk. 3. Consistency: * Inconsistent delta file availability across multiple servers could lead to confusion or errors; * Repositories SHOULD ensure consistent implementation across all servers. 4. Fallback Reliability: * Clients falling back to snapshot updates more frequently could increase load on servers and networks; * Repositories SHOULD monitor fallback frequency and adjust retention policy parameters accordingly. These security considerations do not introduce new vulnerabilities beyond those already present in the RRDP protocol, but they should be carefully addressed in any implementation of the adaptive delta file retention policy. Liu, et al. Expires 23 April 2026 [Page 11] Internet-Draft RRDPDR October 2025 7. IANA Considerations This document has no IANA actions. 8. Normative References [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Zhiwei Yan CNNIC Beijing China Email: yanzhiwei@cnnic.cn Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Liu, et al. Expires 23 April 2026 [Page 12]