| |
|
| |
| | Just because it's an Internet-Draft doesn't mean anything... at all... |
| |
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| | IPv6 is Classless |
| |
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| | Maintaining CCNx or NDN flow balance with highly variable data object sizes |
| |
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| | LSP Ping/Traceroute for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in MPLS networks. The MPLS Node IOAM Information Query functionality uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. |
| | Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
| |
|
This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| | Adaptive Routing Notification |
| |
|
Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and/or improve transport reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, is growing popular in commodity data centers to dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, the sensing node can not only apply AR locally but also send the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the reported path. This document specifies Adaptive Routing Notification (ARN), a general mechanism to proactively disseminate congestion detection and congestion elimination information for remote nodes to perform re-routing policies. Particularly for AI workloads like DeepSeek's MoE models that exhibit dynamic all-to-all communication patterns with bursty traffic characteristics, such mechanisms become crucial to enable immediate network response to transient congestion conflicts. |
| | RDAP Extension for DNS DELEG |
| |
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. |
| | Extending YANG modules at runtime |
| |
|
This document describes a mechanism of signaling extensions to YANG modules that can be used when YANG is not used in an online fashion. |
| | SCHC Rule Format for Message Aggregation in Delay Tolerant Networks |
| |
|
This document defines a new Rule Format for Message Aggregation (referred to as Aggregation) within the SCHC framework. By bundling multiple SCHC-compressed packets into a single Aggregation Data Unit (ADU), the mechanism reduces the number of transmissions required in delay-tolerant networks. The Aggregation process is triggered by conditions such as reaching the L2 Maximum Transmission Unit (MTU), exceeding a maximum delay, or meeting a minimum packet rate threshold. This new rule type is backward compatible with existing SCHC operations and offers an efficient solution for energy-sensitive and asymmetric communication scenarios. |
| | SCHC Reliability Fragmentation |
| |
|
This document specifies a fragmentation mode used for reliability within the SCHC framework. Building on the fragmentation mechanisms defined in RFC8724, this rule format is tailored to ensure the reliable delivery of small messages that do not trigger conventional fragmentation. A key enhancement is the inclusion of a size field, indicating the total byte-length of the message, and modifications to the state machine to support a persistent session with wrap-around windows. Two operational modes are defined: * RelNoAck: A mode derived from SCHC No-Ack fragmentation, where fragments are transmitted without expecting per-fragment acknowledgments. Losses are tolerated within a configured threshold. * RelAckOnErr: A mode derived from SCHC Ack-On-Error fragmentation, where the receiver actively monitors for missing fragments and initiates recovery through explicit negative acknowledgments. These modes offer operators the flexibility to balance recovery overhead against latency and reliability requirements in constrained network environments. |
| | SMPT VERP Service Extension |
| |
|
This specification makes official D. J. Bernstein's Variable Envelope Return Paths: VERP. |
| | IPv5 -- The missing transition step |
| |
|
Despite IPv6 was developed to replace IPv4, the transition process did not and will not ramp up as expected. Major reason for stalled deployment is non-technical, but historical knowledge as well as established processes. The missing part between IPv4 and IPv6 is designed to help the migration efforts by addressing the non- technical needs for a smooth transition. |
| | The Areion Cipher Algorithm and Its Use With IPsec |
| |
|
This document specifies the integration of the Areion cryptographic permutation into IPsec. Areion is a novel cryptographic primitive designed to achieve significantly lower latency for encryption and hashing operations compared to traditional algorithms like AES-GCM, making it particularly suitable for high-performance VPNs and data center interconnect scenarios. This specification defines the use of Areion within Encapsulating Security Payload (ESP), including the associated keying materials and the necessary parameters for Internet Key Exchange (IKE). The Areion permutation is fully described in [I-D.sakemi-areion]. This document focuses on incorporating Areion into IPsec. |
| |
|
| |
| | BGP Dissemination of L2 Flow Specification Rules |
| |
|
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. |
| | Geo-Intelligence Network Based On H3 and LISP |
| |
| | draft-ietf-lisp-nexagon-55.txt |
| | Date: |
30/03/2025 |
| | Authors: |
Sharon Barkai, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Jordi Paillisse, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
Lisp-Nexagon is a geospatial intelligence network protocol designed to support physical-world applications such as transportation, public safety, and logistics. It combines the Locator/ID Separation Protocol (LISP) with the H3 spatial indexing system to enable distributed agents to report, aggregate, and disseminate geospatial state information. |
| | An IPv4 Flowlabel Option |
| |
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. |
| | Applicability of Reliable Server Pooling for Real-Time Distributed Computing |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. |
| | Secure SCTP |
| |
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. |
| | Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility |
| |
|
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). |
| | Reliable Server Pooling (RSerPool) Bakeoff Scoring |
| |
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. |
| | Handle Resolution Option for ASAP |
| |
|
This document describes the Handle Resolution option for the ASAP protocol. |
| | Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling |
| |
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. |
| | Takeover Suggestion Flag for the ENRP Handle Update Message |
| |
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. |
| | SCTP Socket API Extensions for Concurrent Multipath Transfer |
| |
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. |
| | Sender Queue Info Option for the SCTP Socket API |
| |
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. |
| | Ideas for a Next Generation of the Reliable Server Pooling Framework |
| |
|
This document collects some idea for a next generation of the Reliable Server Pooling framework. |
| | Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP) |
| |
|
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. |
| | Security Considerations for Tenant ID and Similar Fields |
| |
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| | Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification |
| |
| | draft-mglt-ipsecme-dscp-np-03.txt |
| | Date: |
30/03/2025 |
| | Authors: |
Daniel Migault, Joel Halpern, Stere Preda, Daiying Liu, U. Parkholm |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. |
| | Direct Knowledge Extension to Distance Vector Routing |
| |
|
Naive Distance Vector-based routing protocols like the Routing Information Protocol [RFC_1058] suffer from a phenomena called the "count to infinity problem" in the event of a network topology change. This Internet Draft extends a naive Distance Vector routing implementation with a simple flag that allows the network to recover quickly and reliably, with no chance of routing loops to occur. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Sebastianmueller22/network-protocol. |
| |
|
| |
| | IGP Extensions for Advertising Node Index |
| |
| | draft-chen-lsr-adv-ni-06.txt |
| | Date: |
29/03/2025 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. |
| | IGP Extensions for Advertising Link Numbers |
| |
| | draft-chen-lsr-adv-lkno-06.txt |
| | Date: |
29/03/2025 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the link numbers assigned to the links originating at a node. |
| | Stateless Best Effort Multicast Using MRH |
| |
| | draft-chen-pim-be-mrh-06.txt |
| | Date: |
29/03/2025 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes stateless best effort Multicast along the shortest paths to the egress nodes of a P2MP Path/Tree. The multicast data packet is encapsulated in an IPv6 Multicast Routing Header (MRH). The MRH contains the egress nodes represented by the indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along the shortest path. There is no state stored in the core of the network. |
| | Stateless Best Effort Multicast Simulations |
| |
| | draft-chen-pim-be-mrh-simu-05.txt |
| | Date: |
29/03/2025 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu, Lei Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes simulations of stateless best effort Multicasts and lists a set of simulation results for different large network sizes and different tree sizes. |
| | The Gordian Envelope Structured Data Format |
| |
|
Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. |
| |
|
| |
| | BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover |
| |
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. |
| | Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item |
| |
|
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/ packet content such as destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items, and Sub-Data Items are defined to support DiffServ and Ethernet traffic classification. |
| | Distribution of SR P2MP Policies and State using BGP-LS |
| |
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. |
| | Source IPv6 Address Programmability |
| |
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information |
| | YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) |
| |
| | draft-li-savnet-sav-yang-06.txt |
| | Date: |
27/03/2025 |
| | Authors: |
Dan Li, Libin Liu, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. |
| | Latency analysis of mobile transmission |
| |
|
Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. |
| | Multiple Hop Unaffiliate BFD |
| |
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. |
| | TOTP Secure Enrollment |
| |
|
This document describes a secure key exchange scheme that extends the Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment method to prevent compromise of the non-expiring TOTP key by photographic capture of the QR code or by intentional or unintentional persistence of the key string in email, SMS, or other systems outside of the TOTP authenticator system itself. |
| | Bits in ABNF |
| |
|
This is an extension to the ABNF specification to allow for bits definitions to be defined. When interacting with hardware or bit oriented over the wire protocols ABNF is not currently the choice. This specification describes a method to add boolean and narrow bit values in order to fix that limitation. And this note while in in draft status: A new Open Source XDR [RFC4506] and ABNF generation tool is being developed [xdrgen] which generates code from ABNF and XDR. It can also generate ABNF from XDR. And it can generate XDR from ABNF. Both also can produce C++ source and header files. |
| | Bits in XDR |
| |
|
This is an extension to the XDR specification to allow for bits to be described and sent. With protocols that have a large number of boolean values the existing standard requires each to be individually packed into a 32-bit value. This addition does not alter any existing XDR data streams or effect existing implementations. * This specification describes how to pack a bit-boolean and short bit-width data values into the 32-bit XDR block chunks. * And this specification describes how to describe them by extending "The XDR Language Specification" to include bits. * And a new namespace declaration type is specified to aid in the reduction of name collisions in large projects. While in draft status, a new Open Source XDR generation tool is being developed [xdrgen]. |
| | Terminology and processes for initial security setup of IoT devices |
| |
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. |
| |
|
| |
| | MPT Network Layer Multipath Library |
| |
| | draft-lencse-tsvwg-mpt-11.txt |
| | Date: |
23/03/2025 |
| | Authors: |
Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu |
| | Working Group: |
Individual Submissions (none) |
|
Although several contemporary IT devices have multiple network interfaces, communication sessions are restricted to use only one of them at a time due to the design of the TCP/IP protocol stack: the communication endpoint is identified by an IP address and a TCP or UDP port number. The simultaneous use of these multiple interfaces for a communication session would improve user experience through higher throughput and improved resilience to network failures. MPT is a network layer multipath solution, which provides a tunnel over multiple paths using the GRE-in-UDP specification, thus being different from both MPTCP and Huawei's GRE Tunnel Bonding Protocol. MPT can also be used as a router, routing the packets among several networks between the tunnel endpoints, thus establishing a multipath site-to-site connection. The version of tunnel IP and the version of path IP are independent from each other, therefore MPT can also be used for IPv6 transition purposes. |
| | Handling and Adoption of Internet-Drafts by IETF Working Groups |
| |
|
The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. |
| | BGP SR Policy Candidate Path State Extend Flags |
| |
|
[draft-ietf-idr-bgp-ls-sr-policy]The SR Candidate Path State TLV conveys the operational status and attributes of an SR Policy at the candidate path level. The SR Candidate Path State is frequently extended to carry new attributes and states for CPaths. However, only a few bits remain unassigned in the Flags field of the current implementation. This document addresses the issue of insufficient flag bits in the SR Candidate Path State TLV by defining a variable-length SR Candidate Path State Extend TLV for BGP-LS SR-Policy. This enhancement ensures scalability and flexibility in signaling additional attributes and states for SR Policy candidate paths. |
| | BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects |
| |
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. |
| | Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 |
| |
| | draft-ietf-tls-ecdhe-mlkem-00.txt |
| | Date: |
23/03/2025 |
| | Authors: |
Kris Kwiatkowski, Panos Kampanakis, Bas Westerbaan, Douglas Stebila |
| | Working Group: |
Transport Layer Security (tls) |
|
This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). |
| |
|
| |
| | Signaling Maximum Transmission Unit (MTU) using BGP-LS |
| |
|
Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture and IPv6 architecture, with a new type of routing header. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path MTU of SR tunnel. However, SR uses the IGP as the routing protocol and does not support the negotiation of the Path MTU. BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This document specifies the extensions to BGP-LS to carry MTU information of link. The centralized controller (PCE/SDN) calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. |
| | Mail Autoconfig |
| |
|
Set up a mail account with only email address and password. |
| | Adding an Uncacheable Attribute to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) allows a client to cache both metadata and data for file objects, as well as metadata for directory objects. While caching directory entries (dirents) can improve performance, it can also prevent the server from enforcing access control on individual dirents. Similarly, caching file data can lead to performance issues if the cache hit rate is low. This document introduces a new uncacheable attribute for NFSv4. Files and dirents marked as uncacheable MUST NOT be stored in client-side caches. This ensures data consistency and integrity by requiring clients to always retrieve the most recent data directly from the server. This document extends NFSv4.2 (see RFC7862). |
| | Double Nonce Derive Key AES-GCM (DNDK-GCM) |
| |
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM). It operates with a 32- byte root key and is designed to encrypt with a 24-byte random nonce and optionally to provide for key commitment. Encryption takes the root key and a 15-byte portion of the random nonce, and derives a fresh 32-byte encryption key and (optionally) a key commitment value. Then, it invokes AES-GCM with the derived key and the remaining bytes of the nonce, and outputs the ciphertext, authentication tag and the key commitment value. Although this is not the primary use case, it is also possible to use DNDK-GCM with a non-repeating but non-random nonce (i.e., a "counter- based nonce"). The low collision probability in a collection of 24-byte random nonces and the per-nonce derivation of an encryption key extend the lifetime of the root key, and the scheme can support processing up to 2^64 bytes under a given root key. DNDK-GCM introduces a relatively small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption that AES acts as a pseudorandom permutation. |
| | CAA Security Tag for Cryptographically-Constrained Domain Validation |
| |
| | draft-birgelee-lamps-caa-security-02.txt |
| | Date: |
21/03/2025 |
| | Authors: |
Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal |
| | Working Group: |
Individual Submissions (none) |
|
Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which may be located between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man-in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically- constrained domain validation procedures. |
| | Destination/Source Routing |
| |
|
This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC8200] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously. |
| |
|
| |
| | RTP over QUIC (RoQ) |
| |
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. |
| | No-Vary-Search |
| |
|
This specification defines a proposed HTTP header field for changing how URL search parameters impact caching. |
| | Operational Guidance for Protection mechanisms in SRv6 Networks |
| |
|
This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks. |
| | An Interplanetary DNS Model |
| |
|
As human activity continues to spread beyond the Earth, so must the communications systems which support that activity continue to expand in scope. One such case, Internet naming, presents particular challenges when considering a multi-planet civilization. Proper operation of terrestrial DNS services and clients require constant, reasonably low latency connectivity to operate properly. These conditions are distinctly not present when considering interplanetary links; high latency and frequent disruption due to space weather events and general link availability prevail. To overcome these challenges in space networking, a delay and distruption tolerant (DTN) suite of protocols has been developed based on a store and forward mechanism, Bundle Protocol(BP). This DTN network, which optimizes to ensure bundle delivery, does not allow for end to end encapsulation of IP packets beyond terrestrial boundaries, as the latency still creates issues completing network transactions, even in the unlikely event of continuous link availability. |
| | Delete-Cookie |
| |
|
This document specifies a Delete-Cookie HTTP header that instructs clients to delete cookies of certain names, without requiring the server to know more details about them. |
| | Updates to OAuth 2.0 Client Asseertion Authentication and Assertion Based Authorization Grants |
| |
|
TODO Abstract |
| | A YANG Data Model and RADIUS Extension for Policy-based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-07.txt |
| | Date: |
20/03/2025 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| |
|
| |
| | YANG-CBOR: Allocating SID ranges for PEN holders |
| |
|
YANG-CBOR, RFC 9254 defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 defines ways to allocate these SIDs on the basis of IANA registries. The present specification uses these SID allocation mechanisms to allocate ranges with 100 000 63-bit SIDs each for each of the first 1 000 000 holders of IANA-registered Private Enterprise Numbers (PENs), as well as ranges with 10 000 32-bit SIDs each for each of the first 100 000 holders. |
| | Generalized DNS Notifications |
| |
|
This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, to allow triggering other types of actions via the DNS that were previously lacking a trigger mechanism. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ). To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the new DSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. |
| | IGP Reverse SPF Algorithm |
| |
|
IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. |
| | The Mojette Transformation for the Erasure Coding of Files in NFSv4.2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flex file layout type version 2 further allows for erasure encoding types to provide data integrity. In this document, a new erasure encoding type for the Mojette Transformation is introduced. |
| | SR Policy Programming RPC |
| |
|
The document specifies a Remote Procedure Call (RPC) for programming ephemeral states associated with an SR Policy. |
| | SCONEPRO Taxonomy of throttling policies used worldwide |
| |
| | draft-zarifis-scone-taxonomy-01.txt |
| | Date: |
19/03/2025 |
| | Authors: |
Kyriakos Zarifis, Sharad Jaiswal, Ilango Purushothaman, Jon Varsanik, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a description of traffic throttling and a taxonomy of throttling policies used by CSPs worldwide. |
| | Requirements for HTTPS for Local Domains |
| |
|
When connecting to servers on their local network, users are surprised to encounter user interfaces that display errors, show insecure connections, and block some HTTP features when missing a secure context. However, obtaining PKIX certificates for those servers is difficult for a variety of reasons. This document explores requirements for authenticating local servers. |
| | PACC - Automatic configuration for mail servers,calendar and contacts sync |
| |
|
Set up a mail account with only email address and password. This uses the DNS SRV mechanism to find the configuration. It is meant for new mail servers that adapt their configuration to current best practices. |
| | Fixed AES-GCM modes for the SSH protocol |
| |
|
This document describes the use of the AES-GCM AEAD in the Secure Shell (SSH) protocol, using the underlying construction of [RFC5647] but fixing problems in the negotiation mechanism. |
| | DPU-Based Bare Metal Management and Control Solution |
| |
|
This document proposes a DPU-based bare metal management solution to address inefficiencies in management and resource utilization associated with traditional bare metal deployments. The core idea of this solution is to leverage the DPU's high-performance processing and network acceleration capabilities, transforming traditional network/resource management into a DPU-centric control model. This not only simplifies bare-metal operations but achieves unified management across virtualized and physical environments through a consolidated framework. |
| | The JSON format for vCon - Conversation Data Container |
| |
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) |
| |
|
| |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | External Trace ID for Configuration Tracing |
| |
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| | Research Challenges in Coupling Artificial Intelligence and Network Management |
| |
| | draft-irtf-nmrg-ai-challenges-05.txt |
| | Date: |
18/03/2025 |
| | Authors: |
Jerome Francois, Alexander Clemm, Dimitri Papadimitriou, Stenio Fernandes, Stefan Schneider |
| | Working Group: |
Network Management (nmrg) |
|
This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, there are many difficult problems in NM that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that networks are operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. |
| | UAS Operator Privacy for RemoteID Messages |
| |
|
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. |
| | Advertisement of Dedicated Metric for Flexible Algorithm in IGP |
| |
|
This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. |
| | Efficient Air-Ground Communications |
| |
|
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery. |
| | Centralized Anycast Gateway in Ethernet VPN(EVPN) |
| |
|
EVPN Integrated Routing and Bridging (IRB) fabrics provide a flexible and extensible method for Layer-2 and Layer-3 overlay network connectivity. [EVPN-IRB] defines operation for symmetric and asymmetric EVPN IRB using distributed anycast gateway architecture (DAG). In a DAG architecture, both bridging and first-hop routing functions for overlay subnets are located on leaf PEs, with first-hop routing provided by a distributed anycast gateway provisioned across the leaf PEs. This document describes an architecture and operation for EVPN Centralized Anycast Gateway (CAG), which allows the first- hop routing function for overlay subnets to be centralized on designated IRB GWs while the bridging function is still located on the leaf PEs. The documents also covers trade-offs of deploying a CAG as compared with DAG. It further describes operation for inter- op between CAG and DAG based EVPN-IRB network overlays. |
| | Secure Shell Key Exchange Method Using Chempat Hybrid of Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512 |
| |
|
This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on Classic McEliece (mceliece6688128) and X25519 with SHA-512 using Chempat as the combiner. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-ssh-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-mceliece. |
| | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
| |
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. |
| | A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET |
| |
|
This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object which carries the list of Autonomous Systems (ASes) deploying inter-domain SAVNET. When validated, the eContent of a SiSPI object confirms that the holder of the listed ASN produces the object and the AS has deployed inter- domain SAV and is ready to establish neighbor relationship for preventing source address spoofing. |
| | SRv6 Service SID Anycast Flag |
| |
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines the Anycast-flag for SRv6 Service SIDs carried in BGP messages. |
| | A method for delivery of SMTP messages over Bundle Protocol networks. |
| |
|
Delay and disruption tolerant networks are a foundational component of Interplanetary Internet communications. This document will treat several methods and modes of operation of Mail Transfer Agents in concert with Bundle Protocol Agents which allow SMTP interoperability between discrete IP networks bridged by DTNs, via Application Layer Gateways. |
| | EUF-CMA for the Cryptographic Message Syntax (CMS) SignedData |
| |
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists a number of potential mitigations for LAMPS working group discussion. |
| | Code Point Exhaustion in OpenPGP |
| |
|
This document specifies variable-length encoding mechanisms to expand the current one-octet OpenPGP registries beyond 256 values. |
| | Secure Shell Key Exchange Method Using Chempat Hybrid of FrodoKEM-976 and X25519 with SHA-512: frodokem976x25519-sha512 |
| |
|
This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on FrodoKEM (FrodoKEM-976) and X25519 with SHA-512 using Chempat as the combiner. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-ssh-frodokem/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-frodokem. |
| |
|
| |
| | Calendar subscription upgrades |
| |
|
This specification updates RFC5545 to add the value DELETED to the STATUS property. This specification also adds values to the Preferences Registry defined in RFC7240 to add the subscribe-enhanced-get and limit preferences and to the link relations directory defined in RFC8288. |
| | A YANG Data Model for Flexi-Grid Optical Networks |
| |
| | draft-ietf-ccamp-flexigrid-yang-18.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Universidad de Madrid, Daniel Burrero, Daniel King, Young Lee, Haomian Zheng |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Aggregate Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record. |
| | RateLimit header fields for HTTP |
| |
|
This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. |
| | BGP Community Container Attribute |
| |
|
Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. This document defines a new encoding that enhances and simplifies what can be accomplished with BGP communities. This specification's most important addition is the ability to specify and advertise an operator's parameters for execution. It also provides an extensible platform for any future community encoding requirements. |
| | Registered Wide BGP Community Values |
| |
|
Communicating various routing policies via route tagging plays an important role in external BGP [RFC4271] peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities [RFC1997]. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. |
| | Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members |
| |
|
In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) [IEEE802.1AX]) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE, it is essential to know the connectivity relationships among bundle members. This document describes how OSPF and IS-IS would advertise the remote interface identifiers for Layer 2 bundle members. The corresponding extension of BGP-LS is also specified. |
| | Load Sharing for the Stream Control Transmission Protocol (SCTP) |
| |
| | draft-tuexen-tsvwg-sctp-multipath-29.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. |
| | NEAT Sockets API |
| |
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. |
| | The R5N Distributed Hash Table |
| |
| | draft-schanzen-r5n-07.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Martin Schanzenbach, Christian Grothoff, Bernd Fix |
| | Working Group: |
Individual Submissions (none) |
|
This document contains the R^5N DHT technical specification. R^5N is a secure distributed hash table (DHT) routing algorithm and data structure for decentralized applications. It features an open peer- to-peer overlay routing mechanism which supports ad-hoc permissionless participation and support for topologies in restricted-route environments. Optionally, the paths data takes through the overlay can be recorded, allowing decentralized applications to use the DHT to discover routes. This document defines the normative wire format of protocol messages, routing algorithms, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to guide implementation of R^5N and to ensure interoperability among implementations including the pre-existing GNUnet implementation. |
| | IP Addressing with References (IPREF) |
| |
|
IP addressing with references, or IPREF for short, is a method for end-to-end communication across different address spaces normally not reachable through native means. IPREF uses references to addresses instead of real addresses. It allows to reach across NAT/NAT6 and across protocols IPv4/IPv6. It is a pure layer 3 addressing feature that works with existing network protocols. IPREF forms addresses (IPREF addresses) made of context addresses and references. These IPREF addresses are publishable in Domain Name System (DNS). Any host in any address space, including behind NAT/ NAT6 or employing different protocol IPv4/IPv6, may publish IPREF addresses of its services in DNS. These services will be reachable from any address space, including those running different protocol IPv4/IPv6 or behind NAT/NAT6, provided both ends support IPREF. IPREF is especially useful for transitioning to IPv6 or for operating networks with a mix of IPv4/IPv6. |
| | LibrePGP Message Format |
| |
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| | Distributed Symmetric Key Establishment (DSKE) |
| |
| | draft-mwag-dske-02.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Mattia Montagna, Manfred von Willich, Melchior Aelmans, Gert Grammel |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a robust, scalable, and future-proofed security protocol for Symmetric Key Distribution without reliance on asymmetric encryption. This document delineates the protocol's specifications, security model, and architectural integration of the Distributed Symmetric Key Establishment (DSKE) protocol. Note This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. |
| | SEARCH -- a New Slow Start Algorithm for TCP and QUIC |
| |
| | draft-chung-ccwg-search-06.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Jae Chung, Maryam Kachooei, Feng Li, Mark Claypool |
| | Working Group: |
Individual Submissions (none) |
|
TCP slow start is designed to ramp up to the network congestion point quickly, doubling the congestion window each round-trip time until the congestion point is reached, whereupon TCP exits the slow start phase. Unfortunately, the default Linux TCP slow start implementation -- TCP Cubic with HyStart [HYSTART] -- can cause premature exit from slow start, especially over wireless links, degrading link utilization. However, without HyStart, TCP exits slow start too late, causing unnecessary packet loss. To improve TCP slow start performance, this document proposes using the Slow start Exit At Right CHokepoint (SEARCH) algorithm [KCL24] where the TCP sender determines the congestion point based on acknowledged deliveries -- specifically, the sender computes the delivered bytes compared to the expected delivered bytes, smoothed to account for link latency variation and normalized to accommodate link capacities, and exits slow start if the delivered bytes are lower than expected. We implemented SEARCH as a Linux kernel v5.16 module and evaluated it over WiFi, 4G/LTE, and low earth orbit (LEO) and geosynchronous (GEO) satellite links. Analysis of the results show that the SEARCH reliably exits from slow start after the congestion point is reached but before inducing packet loss. |
| | Intent for Green Services |
| |
|
There is an increasing interest on incorporating sustainable dimension to the provision of commnunication services. This document describes an intent for allowing customers to express their desired intents in terms of the green service objectives they expect from the network provider. |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | In-Place Bandwidth Update for MPLS RSVP-TE LSPs |
| |
|
This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB). |
| | 3GPP-IETF Standardization Collaboration |
| |
| | draft-kes-rfc3113bis-00.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Suresh Krishnan, Charles Eckel, Peter Schmitt |
| | Working Group: |
Individual Submissions (none) |
|
This document contains a set of principles and guidelines that serve as the basis for the collaboration between 3GPP and IETF, with the objective of securing timely development of technical specifications, and to facilitate maximum interoperability with existing fixed and mobile Internet systems, devices, and protocols. |
| | RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement |
| |
|
This document describes a mechanism for signaling which video frames have been received and decoded by a remote peer. It comprises an RTCP feedback message and an RTP header extension used to request said feedback. One of the main use cases for this data is to implement various forms of Long Term Reference (LTR) reference structures. |
| | Decentralized Messaging Layer Security |
| |
|
Messaging Layer Security provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). However, MLS requires a Delivery Service (DS) to facilitate agreement between group members on the order of Commit messages. In decentralized settings the only way to implement a functional DS is to require group members to retain key material so they can process commits out-of-order. Retaining key material this way is in violation of the MLS deletion schedule and significantly reduces the FS of the protocol. This draft specifies Decentralized MLS, based on the the Fork-Resilient Continuous Group Key Agreement protocol FREEK proposed by Alwen et al. [FRCGKA]. In essence, DMLS extends MLS such that key material can be retained to process Commits out-of-order with minimal losses to FS, thus allowing safer deployment in decentralized environments. |
| | FrodoKEM: key encapsulation from learning with errors |
| |
| | draft-longa-cfrg-frodokem-00.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Patrick Longa, Joppe Bos, Stephan Ehlen, Douglas Stebila |
| | Working Group: |
Individual Submissions (none) |
|
This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. |
| | A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network |
| |
| | draft-ietf-rtgwg-atn-bgp-28.txt |
| | Date: |
17/03/2025 |
| | Authors: |
Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on industry-standard BGP to address the ATN/IPS requirements. |
| | Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests |
| |
|
This specification describes extensions to the SUIT manifest format. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. |
| |
|
| |
| | Conditional Query Parameters for CoAP Observe |
| |
|
This specification defines Conditional Notification and Control Query Parameters compatible with CoAP Observe (RFC7641). |
| | BMP Loc-RIB: Peer address |
| |
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. |
| | Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this transform type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". |
| | IPlir network layer security protocol |
| |
| | draft-iplir-protocol-07.txt |
| | Date: |
16/03/2025 |
| | Authors: |
Martishina Alexandra, Urivskiy Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. |
| | Asynchronous Deterministic Networking Framework for Large-Scale Networks |
| |
|
This document describes various solutions of Asynchronous Deterministic Networking (ADN) for large-scale networks. The solutions in this document do not need strict time-synchronization of network nodes, while guaranteeing end-to-end latency or jitter. The functional architecture and requirements for such solutions are specified. |
| | A Larger Internet Key Exchange version 2 (IKEv2) Payload |
| |
|
The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document defines an extension to IKEv2 that allows larger payloads. |
| | BGP FlowSpec Extension for Traffic Scheduling |
| |
|
Traditional QoS technology can not achieve fine adjustment in the traffic scheduling, and has a large amount of configuration and poor maintainability. BGP FlowSpec technology provides a wealth of filtering conditions and processing actions, using BGP network layer reachable information (NLRI) to transmit traffic filtering information, which can achieve a more fine-grained control of the traffic and improve maintainability. This document defines the extension of BGP FlowSpec, adding two new traffic filtering actions for extended community: minimum rate guarantee and congestion management, to enable better management and scheduling of traffic, and further improving the scalability and applicability of BGP FlowSpec. |
| | Source Buffer Management |
| |
|
In the past decade there has been growing awareness about the harmful effects of bufferbloat in the network, and there has been good work on developments like L4S to address that problem. However, bufferbloat on the sender itself remains a significant additional problem, which has not received similar attention. This document offers techniques and guidance for host networking software to avoid network traffic suffering unnecessary delays caused by excessive buffering at the sender. These improvements are broadly applicable across all datagram and transport protocols (UDP, TCP, QUIC, etc.) on all operating systems. |
| | RTP Header Extension for Automatic Detection of Video Corruptions |
| |
|
This document describes an RTP header extensions that can be use to carry select filtered samples from a video frame together with metrics relating to the expected distortions caused by lossy compression of said frame. This data allows a receiver to validate that the output from a decoder matches the frame the went into the encoder on the remote - i.e. validating that the video pipeline is in a correct state free of any video corruptions. |
| | TLS For Secure Element Rendez Vous |
| |
|
TLS for Secure Element (TLS-SE) is a TLS 1.3 profile for secure element. The pre-shared-key (psk) mode requires two security attributes, psk-identity and psk value, somewhat similar to login and password parameters used for classical users accounts. A rendez vous mechanism works with two accounts with different privileges. A root account generates contents and creates guest account with dedicated access rights for these contents. It is a kind of trusted publish-subscribe mechanism based on a TLS1.3 server running in a secure element. |
| | Methods for Mitigation of Congestion and Load Issues on RADIUS Servers |
| |
|
The RADIUS protocol as defined in [RFC2865] does not have a means to signal server overload or congesition to the clients. This can lead to load problems, especially in a federated RADIUS proxy fabric. This document attempts to fix this. |
| | Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 17.0.0 |
| |
|
This document describes the changes between Unicode 12.0.0 and Unicode 17.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. The review assigns the derived property value "UNDER REVIEW" to certain code points. This is added as exceptions to the algorithm for IDNA2008 that allows adding exceptions to the algorithm for backward compatibility exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 17.0.0. |
| | Transport Options for UDP |
| |
|
Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram. |
| |
|
| |
| | Bundle-in-Bundle Encapsulation |
| |
| | draft-ietf-dtn-bibect-05.txt |
| | Date: |
15/03/2025 |
| | Authors: |
Scott Burleigh, Alberto Montilla, Joshua Deaton, Carlo Caini |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called Bundle Retransmission Methods (BRM). This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol (version 6) specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. |
| | Reflexive Forwarding for CCNx and NDN Protocols |
| |
|
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. |
| | Challenges and Opportunities in Management for Green Networking |
| |
| | draft-irtf-nmrg-green-ps-06.txt |
| | Date: |
15/03/2025 |
| | Authors: |
Alexander Clemm, Carlos Pignataro, Cedric Westphal, Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini |
| | Working Group: |
Network Management (nmrg) |
|
Reducing humankind's environmental footprint and making technology more environmentally sustainable are among the biggest challenges of our age. Networks play an important part in this challenge. On one hand, they enable applications that help to reduce this footprint. On the other hand, they contribute to this footprint themselves in no insignificant way. Therefore, methods to make networking technology itself "greener" and to manage and operate networks in ways that reduce their environmental footprint without impacting their utility need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become "greener", i.e., more sustainable, with reduced greenhouse gas emissions and less negative impact on the environment. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. |
| | Merkle Tree Ladder (MTL) Mode Signatures |
| |
|
This document provides an interoperable specification for Merkle tree ladder (MTL) mode, a technique for using an underlying signature scheme to authenticate an evolving series of messages. MTL mode can reduce the signature scheme's operational impact. Rather than signing messages individually, the MTL mode of operation signs structures called "Merkle tree ladders" that are derived from the messages to be authenticated. Individual messages are then authenticated relative to the ladder using a Merkle tree authentication path and the ladder is authenticated using the public key of the underlying signature scheme. The size and computational cost of the underlying signatures are thereby amortized across multiple messages, reducing the scheme's operational impact. The reduction can be particularly beneficial when MTL mode is applied to a post-quantum signature scheme that has a large signature size or computational cost. As an example, the document shows how to use MTL mode with the Stateless Hash-Based Digital Signature Algorithm (SLH- DSA) specified in the draft FIPS 205. Like other Merkle tree techniques, MTL mode's security is based only on cryptographic hash functions, so the mode is quantum-safe based on the quantum- resistance of its cryptographic hash functions. |
| | IGP-based Source Prefix Advertisement for Intra-domain SAVNET |
| |
|
SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS. |
| | MoQ Media Interop |
| |
|
This protocol can be used to send and receive video and audio over Media over QUIC Transport [MOQT], using LOC[loc] packaging. |
| | Enhanced JWE Security with Detached Additional Authenticated Data (AAD) |
| |
|
This draft introduces a mechanism to support detached Additional Authenticated Data (AAD) in JWE (JSON Web Encryption), allowing the AAD to be derived from context-specific information, such as session identifiers, algorithm identifiers, and identifiers of communication endpoints, rather than being transmitted in-band. This mechanism strengthens security by mitigating risk against unknown-key-share attacks and/or other exploitation techniques that depend on some type of confusion over the role played by each party. The document explains how to integrate this functionality into JWE, covering both JWE JSON Serialization and JWE Compact Serialization. |
| | Multicast Snooping Optimizations |
| |
|
TODO: provide abstract |
| | BGP-Link State (BGP-LS) Advertisement of Flow Queue |
| |
|
In the traffic congestion management of routers, queueing technology is generally used to classify and transmit traffic. Therefore, queue information indirectly reflects the congestion status of the router. This document makes the necessary expansion of the BGP-LS mechanism to send queue information to the network controller in a scalable way, enabling the network controller to understand the router's traffic congestion status and make appropriate adjustments to the network traffic. |
| | Proposal for Updates to Guidance on Packet Reordering |
| |
|
Several link technology standards mandate that equipment guarantee in-order delivery of layer 2 frames, apparently due to a belief that this is required by higher layer protocols. In addition, certain link types can introduce out-of-order arrivals at the end of the layer 2 link, which the receiving equipment is required to rectify by delaying higher sequenced frames until all lower sequenced frames can be delivered or are deemed lost. The delaying of higher sequenced frames is generally done without any knowledge of the higher layer protocols in use, let alone any knowledge of higher layer protocol contexts (e.g. TCP connections) in the case that the layer 2 link is carrying a multiplex of such contexts. It could, for example, be the case that all of the higher sequenced frames being delayed are carrying packets for different layer 4 contexts than a single lower- sequenced frame that triggered the delay. The result is that this "re-sequencing" operation can introduce delays that result in degradation of performance rather than improving it. Moreover, modern, performant TCP and QUIC implementations support features that significantly improve their tolerance to out-of-order delivery. This draft is intended to promote an analysis and discussion of the sensitivity of modern IETF protocols to out-of-order delivery, and to potentially develop new information for layer 2 technology standards regarding the need to assure in-order delivery to support IETF protocols. |
| | Distributed MLS |
| |
|
The Messaging Layer Security (MLS) protocol enables a group of participants to negotiate a common cryptographic state for messaging, providing Forward Secrecy (FS) and Post-Compromise Security (PCS). Still, there are some use cases where message ordering challenges may make it difficult for a group of participants to agree on a common state or use cases where reaching eventual consistency is impractical for the application. This document describes Distributed-MLS (DMLS), a protocol for using MLS sessions to protect messages among participants without negotiating a common group state. |
| | SOCKS Protocol Version 5a |
| |
|
This document describes SOCKS Protocol Version 5a (SOCKS5a), an evolution of the SOCKS Version 5 protocol [RFC1928] designed to enhance security, authentication flexibility, and resistance to traffic analysis while maintaining complete backward compatibility. SOCKS5a introduces optional extensions that allow existing SOCKS5 clients and servers to interoperate with newer, more secure implementations. |
| | A Flags Extension for TLS 1.3 |
| |
|
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. |