| |
|
| |
| | FN-DSA for JOSE and COSE |
| |
| | draft-ietf-cose-falcon-03.txt |
| | Date: |
12/10/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Hannes Tschofenig |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 206 (expected to be published in late 2026 early 2027). It does not define new cryptographic primitives; rather, it specifies how existing FN-DSA mechanisms are serialized for use in JOSE and COSE. This document registers signature algorithms for JOSE and COSE, specifically FN-DSA-512 and FN-DSA-1024. |
| | SLH-DSA for JOSE and COSE |
| |
|
This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post- Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made and part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | Formal SignWriting |
| |
|
Formal SignWriting is a character encoding model for Sutton SignWriting, a script for writing sign languages recognized under ISO 15924 script code "Sgnw". It defines a sign as a two-part word, represented as a string of characters processable by regular expressions, optimized for display, searching, sorting, and text processing. This document specifies the character sets, grammar, token patterns, and technical integration for Formal SignWriting in ASCII (FSW) and SignWriting in Unicode (SWU), including styling, query language, and transformations. The specification is intended for implementation and evaluation, with unrestricted distribution. |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | Public Key Derived HMAC for JOSE |
| |
| | draft-bastian-jose-dvs-02.txt |
| | Date: |
12/10/2025 |
| | Authors: |
Paul Bastian, Micha Kraus, Stefan Santesson, Peter Altmann |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines the use of a Diffie-Hellman key agreement (DH-KA) protocol combined with a key derivation function (KDF) to derive a symmetric Message Authentication Code (MAC) key from public information conveyed within a JSON Web Signature (JWS). |
| | Considerations for SRv6 MSD Limitation in PCEP |
| |
|
This document analyzes the impact of different SRv6 MSDs when PCE sends SR-TE paths to the PCE. And it updates the MSD restrictions in RFC9603 based on the analysis. This document also specifies a procedure for optimizing the number of SIDs in an SRv6-TE path that PCE can compute when the reduced SRH mode is used. |
| | DNSSEC Key Restore |
| |
|
This document describes the issues surrounding the handling of DNSSEC private keys in a DNSSEC signer. It presents operational guidance in case a DNSSEC private key becoming inoperable. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/fobser/draft-fobser-dnsop-dnssec-keyrecovery. |
| | A Survey to Determine MPLS Label Stack Inspection Behavior |
| |
|
As part of the work on MPLS Network Actions (MNA) a debate arose concerning how existing MPLS implementations handle Special Purpose Labels (SPLs) especially in the context of processing the MPLS Entropy Label. The question applies to the relative placement of the Entropy Label Indicator (ELI) and the MNA Base SPL in the MPLS label stack. This question is applicable to the use of the ELI and any new base SPL (bSPL), or to the relative placement of any two bSPLs including the Extension Label that precedes any extended SPL. In order to discover what deployed implementations currently do, it is proposed that the MPLS working group chairs poll participants to answer specific questions about their implementations. This document is a working draft of the questions to be asked. It is not intended that this document should progress to publication as an RFC. |
| | Public Key Derived HMAC for JOSE |
| |
| | draft-bastian-jose-pkdh-00.txt |
| | Date: |
12/10/2025 |
| | Authors: |
Paul Bastian, Micha Kraus, Stefan Santesson, Peter Altmann |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines the use of a Diffie-Hellman key agreement (DH-KA) protocol combined with a key derivation function (KDF) to derive a symmetric Message Authentication Code (MAC) key from public information conveyed within a JSON Web Signature (JWS). |
| | PCE Redundancy Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). A PCE redundance case is very important and has no real solution for many cases, like as active-standby, active-active or not concurrent sessions of PCC with different PCEs. This document proposes extensions to PCEP to allow a PCC and PCEs to support PCE fast and smooth redundancy in case of PCEP session and PCE failure. |
| |
|
| |
| | SDP Offer/Answer for RTP over QUIC (RoQ) |
| |
|
This document is intended to allow the use of QUIC as an underlying transport protocol for RTP applications that commonly use SDP as a session signaling protocol to set up RTP connections, such as SIP and WebRTC. The document describes several new SDP "proto" and "attribute-name" attribute values in the "Session Description Protocol (SDP) Parameters" IANA registry that can be used to describe QUIC transport for RTP and RTCP packets, and describes how SDP Offer/ Answer can be used to set up an RTP connection using QUIC. This document also contains non-normative guidance for implementers. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-28.txt |
| | Date: |
11/10/2025 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. |
| | DetNet multidomain extensions |
| |
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. |
| | Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network |
| |
|
This document describes the use cases and related requirements of Massive Data Transmission（MDT）in High Bandwidth-delay Product (BDP) Network. The MDT framework enables efficient use of nighttime idle bandwidth to provide services such as same-day or next-day delivery. To meet these objectives, the system introduces a terminal-driven intelligent parameter optimization method that adjusts local configurations (e.g., disk I/O, NIC bandwidth, TCP buffer) to match transmission goals. This document outlines the end-to-end architecture and key mechanisms including service identification and traffic statistics, network layer load balancing, transmission protocol optimization, collaboration between terminal APP, network device and controller, etc. |
| | DKIM Access Control and Differential Changes |
| |
|
This document specifies a DKIM (RFC 6376) extension that allows cryptographic verification of SMTP (RFC 5321) envelope data, and of DKIM signatures prior to IMF (RFC 5322) message content changes along the message path, addressing thus security glitches, and offering a new world of email solutions that move complexity away from lower network layers, where problems cannot be solved, complying with David Wheeler's fundamental theorem of software engineering, that "We can solve any problem by introducing an extra level of indirection". It updates DKIM to obsolete certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. It is the future of email for email of the future. |
| | CBOR Serialization and Determinism |
| |
|
This document defines two CBOR serializations: "ordinary serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the full, variable set of serialization options defined in [STD94]. Together, these three form a complete set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. |
| | Proactive Flow Control Point Detection in WAN |
| |
|
This document proposes a proactive detection mechanism for flow control in WAN, letting the congested node to know precisely which upstream point should the flow control message be sent to. |
| | xxHash fast digest algorithm |
| |
|
Description of the xxHash fast digest algorithm. 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-xxhash/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-xxhash. |
| | The Base16,Base32,and Base64 Data Encodings |
| |
|
This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. This document obsoletes RFC 4648 and changes the status to Internet Standard. |
| | SCIM Agents and Agentic Applications Extension |
| |
|
The System for Cross-domain Identity Management (SCIM) specification [RFC7643] provides schemas that represent common identity information about users and groups, as well as a protocol for communicating that information between systems. The systems that tend to implement SCIM clients and servers are identity providers, and service providers. These are the same systems that are now need to manage agents and agentic applications across domains. This document describes a SCIM 2.0 extension for agents and agentic applications, which includes extensions to the core User and Group objects, and new resource types and schemas for agentic constructs. This extension is intended to provide greater interoperability between Identity providers, agentic applications, agents and their clients while reducing the responsibilities assumed by the every growing list of new protocols for agents. |
| |
|
| |
| | A YANG Data Model for Optical Impairment-aware Topology |
| |
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for a Wavelength Switched Optical Network (WSON), while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for a Spectrum Switched Optical Network (SSON). This document provides a YANG data model for the impairment-aware TE topology in optical networks. |
| | Common YANG Data Types for Layer 0 Optical Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-18.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | BMP v4: TLV Support for BGP Monitoring Protocol (BMP) Route Monitoring and Peer Down Messages |
| |
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types. Additionally, this document introduces support for enterprise- specific TLVs in the BGP Monitoring Protocol by defining an Enterprise Bit (E-bit) that allows usage of per-vendor Type values. |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-11.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid |
| | Working Group: |
IP Performance Measurement (ippm) |
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. |
| | A YANG Module for Entitlement Inventory |
| |
|
This document proposes a YANG module for incorporating entitlements in a network inventory, encompassing both virtual and physical network elements. Entitlements define the rights for their holder to use specific capabilities in a network element(s). The model is rooted by the concept of the capabilities offered by an element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-12.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML- DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. |
| | Proxying Ethernet in HTTP |
| |
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. |
| | Crowd Sourced Remote ID |
| |
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| | BGP Extensions of SR Policy for Headend Behavior |
| |
|
RFC8986 defines H. Encaps behavior, H. Encaps.Red behavior, H. Encaps.L2 behavior, and H. Encaps.L2.Red behavior for SR policy. This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. |
| | Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) Framework |
| |
| | draft-fu-cats-oam-fw-04.txt |
| | Date: |
10/10/2025 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Quan Xiong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the OAM framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and OAM components. It also describes the requirements to enable the fault and the performance management of end-to-end connections from clients to networks and finally to services instances. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | RPP Architecture |
| |
|
Advancements in development, integration, deployment environments and operational paradigms have led to a desire for an alternative for the Extensible Provisioning Protocol (EPP). This document defines the architecture for the RESTful Provisioning Protocol (RPP) an HTTP based provisioning protocol leveraging the REST architectural style and JSON data-interchange format, aiming to standardize a RESTful protocol for provisioning database objects. The architecture includes support for extensibility, allowing for multiple possible use cases. RPP is intended to co-exist with EPP, offering an alternative protocol including data model compatibility with EPP core objects and the benefits associated with the REST architectural style and widely adopted HTTP-based technologies. |
| | Computing Energy Consumption Path in Segment Routing Networks |
| |
|
This document describes a method for computing energy consumption paths in Segment Routing (SR) networks, aiming to optimize network traffic routing for energy efficiency, including procedures for energy consumption data collection, path calculation, and issuance, as well as considerations for data plane implementation in both MPLS SR and SRv6 networks. |
| | 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. |
| | Announce Existence of Parent CDS/CSYNC Scanner |
| |
|
In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties. This document proposes an extension to the semantics of the DSYNC resource record, as defined in [RFC9859], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP as described in RFC9604. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. |
| | Best Current Practice for ROA Issuance Restrictions in RPKI |
| |
| | draft-zhang-rpki-roa-bcp-00.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Heng Zhang, zouhui, Likun Zhang, Xue Yang, Di Ma, Yanbiao Li |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It mandates that a parent Certification Authority (CA) MUST NOT issue ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are required to enforce this restriction by rejecting or flagging invalid ROAs issued outside of resource allocations. |
| | Exchanging Congestion Control Data in QUIC |
| |
|
This draft defines a new transport frame which enables consenting endpoints to share congestion control state about the network connection for various purposes. It also allows an endpoint's own congestion control state to be echoed back to it by a peer for consideration at the beginning of a future connection. |
| | Applicability of CATS Framework |
| |
| | draft-jlmcyp-cats-applicability-00.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Tianji Jiang, Luis Contreras, Mark Watts, Carlos Bernardos, shangyuxiang, Peng Liu |
| | Working Group: |
Individual Submissions (none) |
|
The IETF CATS WG considers the problem of how the network edge can steer traffic between clients of a service and the sites offering the service. The service QoE and/or the performance experienced by edge clients may depend on both network metrics and compute metrics. CATS leverages these metrics and strives to optimize how a network edge node may steer traffic, as appropriate to the service. Revolving around the 'optimized' objective, the CATS Framework proposes and defines a general architecture for the distribution of network and compute metrics and for the transport of traffic from network edge to service instance. This draft illustrates the applicability of the CATS framework to various noteworthy scenarios. |
| | PKIX Evidence for Remote Attestation of Hardware Security Modules |
| |
| | draft-ietf-rats-pkix-key-attestation-02.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Mike Ounsworth, Jean-Pierre Fiset, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document specifies a vendor-agnostic format for evidence produced and verified within a PKIX context. The evidence produced this way includes claims collected about a cryptographic module and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce evidence tailored for expected use. |
| | General Source Address Validation Capabilities |
| |
|
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. |
| | Protocol Numbers for SCHC |
| |
|
This document requests an Internet Protocol Number, an Ethertype assignment and well known ports for SCHC. The SCHC architecture, the SCHC instance establishment, and the SCHC compression/decompression processes are simplified when SCHC is easily recognised. Well-known protocol and port numbers are needed. The Internet Protocol Number request is so that SCHC can be used for IP independent of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-22.txt |
| | Date: |
10/10/2025 |
| | Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. |
| | Automatically Connecting Stub Networks to Unmanaged Infrastructure |
| |
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). |
| | Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs |
| |
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| | TVR (Time-Variant Routing) Requirements |
| |
|
Time-Variant Routing (TVR) refers to calculating a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements where TVR computations could improve message exchange in a network. |
| |
|
| |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. |
| | Advanced BGP Monitoring Protocol (BMP) Statistics Types |
| |
|
RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines new statistics type to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs). |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This draft defines a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwardings (VRFs) are exchanged through a single shared Border Gateway Protocol (BGP) session. |
| | YANG Data Model for Automatic Multicast Tunneling |
| |
| | draft-ietf-mboned-amt-yang-05.txt |
| | Date: |
09/10/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Xuesong Geng, Vinod Nagaraj |
| | Working Group: |
MBONE Deployment (mboned) |
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | YANG Schema Comparison |
| |
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) |
| |
| | draft-li-savnet-sav-yang-07.txt |
| | Date: |
09/10/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. |
| | 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. |
| | Advertising Flexible Algorithm Extensions in BGP Link-State |
| |
|
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. |
| | Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV) |
| |
|
This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact. |
| | A Bound End-to-End Tunnel (BEET) mode for ESP |
| |
|
This document is an update to the Bound End-to-End Tunnel (BEET) mode for ESP in as described in [RFC7402]. It brings the description in alignment with the addition of BEET mode for IKEv2 without any processing changes as described in [RFC7402] |
| | ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. |
| | Congestion Control Based on SRv6 Path |
| |
| | draft-liu-rtgwg-srv6-cc-00.txt |
| | Date: |
09/10/2025 |
| | Authors: |
Yisong Liu, Shuping Peng, Changwang Lin, Xiao Min |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. |
| | Indication of Load-balancing Strategy |
| |
|
This document proposes the encoding of the indication for load- balancing strategies which can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. It also provides the considerations for load-balancing configuration in control plane as well. |
| | PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters |
| |
| | draft-ietf-openpgp-nist-bp-comp-00.txt |
| | Date: |
09/10/2025 |
| | Authors: |
Quynh Dang, Stephan Ehlen, Stavros Kousidis, Johannes Roth, Falko Strenzke |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines PQ/T composite schemes based on ML-KEM and ML- DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol. |
| | Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-sid-algo-27.txt |
| | Date: |
09/10/2025 |
| | Authors: |
Samuel Sidor, Zoey Rose, Shaofu Peng, Shuping Peng, Andrew Stone |
| | Working Group: |
Path Computation Element (pce) |
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document introduces extensions in three main areas. Mechanisms for informing PCEP peers about the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects. This document updates RFC 8664 and RFC 9603 to allow such extension. The document specifies SR-Algorithm constraint, enabling refined path computations that can leverage IGP algorithm logic, including Flexible Algorithms, and their associated constraints and optimization metrics. It defines new metric types for the METRIC object required to support SR-Algorithm based path computation, but also applicable to Label Switched Paths (LSPs) setup using different Path Setup Types. |
| | Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping |
| |
|
SR Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanism and installed via, e.g., a Path Computation Element (PCE). In other cases these policies can be installed via using NETCONF/YANG or CLI. They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers. This document defines extensions to Ping and Traceroute mechanisms for SR P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities. The extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within SR P2MP Policy multicast trees. By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing SR P2MP Policies. |
| | Epoch Markers |
| |
|
This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-16.txt |
| | Date: |
09/10/2025 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture |
| |
|
| |
| | Optimizing BFD Authentication |
| |
|
This document describes an experimental optimization to BFD Authentication. This optimization enables BFD to scale better when there is a desire to use authentication where applying the same authentication mechanism to every BFD Control Packet may adversely impact performance. This optimization partitions BFD Authentication into a more computationally intensive mechanism that is applied to BFD significant changes, and a less computationally intensive mechanism applied to the majority of BFD Control Packets. |
| | Meticulous Keyed ISAAC for BFD Optimized Authentication |
| |
|
This document describes a BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate some BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the Up state. |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | QUIC-Aware Proxying Using HTTP |
| |
| | draft-ietf-masque-quic-proxy-07.txt |
| | Date: |
08/10/2025 |
| | Authors: |
Tommy Pauly, Eric Rosenberg, David Schinazi |
| | Working Group: |
Multiplexed Application Substrate over QUIC Encryption (masque) |
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. |
| | Sub-interface VLAN YANG Data Models |
| |
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic originating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| | Inter Domain considerations for Constrained Route distribution |
| |
|
RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). RFC4684 addresses both intra domain and inter domain distributions. Operational deployment experience shows that the current distribution model defined in RFC4684 for inter domain may cause some issue in specific scenarios. This document proposes alternate route distribution rules for inter domain in order to address these specific scenarios. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation information in the DNS. |
| | Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification |
| |
| | draft-mglt-ipsecme-dscp-np-04.txt |
| | Date: |
08/10/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. |
| | A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks |
| |
|
This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to the operation of an IEEE 802.11 wireless network. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. To foster interoperability, deterministic encoding is mandated. Furthermore, the document outlines how deterministic encoding combined with enhanced CBOR tools, enable cryptographic methods like signing and hashing, to optionally use "raw" (non-wrapped) CBOR data as input. This document mainly targets CBOR tool developers. |
| | AgentDNS: A Root Domain Naming System for LLM Agents |
| |
| | draft-liang-agentdns-00.txt |
| | Date: |
08/10/2025 |
| | Authors: |
ZhiyuanLiang, Enfang Cui, Yujun Cheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes AgentDNS, a root domain naming and service discovery system designed for Large Language Model (LLM) agents. Inspired by the traditional Domain Name System (DNS), AgentDNS enables agents to autonomously discover, resolve, and securely invoke third-party agent and tool services across different vendors. AgentDNS introduces a unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication and billing. The system aims to address interoperability, service discovery, and trust management challenges in large-scale agent collaboration ecosystems. |
| | OAuth Client ID Metadata Document |
| |
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. |
| | Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an multi-domain IPv6-only environment(i.e.,IPv4-as- a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, examines the utilization of SRv6, and discusses the security considerations. |
| |
|
| |
| | RTP Payload Format for SFrame |
| |
|
This document describes the RTP payload format of SFrame. |
| | Problem Statement and Requirements for an Improved DNS Delegation Mechanism abbrev: DNS DELEG Requirements |
| |
|
Authoritative control of parts of the Domain Name System namespace are indicated with a special record type, the NS record, that can only indicate the name of the server which a client resolver should contact for more information. Any other features of that server must then be discovered through other mechanisms. This draft considers the limitations of the current system, benefits that could be gained by changing it, and what requirements constrain an updated design. |
| | Integration of DNS Domain Names into Application Environments: Motivations and Considerations |
| |
|
This document describes considerations when integrating a DNS domain name into an application environment. Goals of this document include minimizing conflicts between the global DNS and applications that integrate with the global DNS, providing a consistent user experience (unique identifier across environments), and extending the security, stability, and resiliency of the global DNS. While all sources of potential concern cannot be enumerated in one document, accounting for at least the considerations discussed here should improve the security posture of both the global DNS and integrating applications. |
| | BGP Operations and Security |
| |
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability requirements that can and should be ensured to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454 / BCP194, several developments and changes in operational practice took place that warrant an update of these best current practices. This document replaces RFC7454 / BCP194, focusing on the overall goals, and providing a less implementation centric set of best practices. This document describes security requirements and goals when operating BGP for exchanging routing information with other networks, and explicitly does not focus on specific technical implementations and requirements. |
| | Currently Used Terminology in Global Routing Operations |
| |
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. |
| | Current Options for Securing Global Routing |
| |
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. |
| | Transaction ID Mechanism for NETCONF |
| |
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration datastores. The volume of configuration data in a server may be very large, while datastore changes typically are small when observed at typical client resynchronization intervals. Rereading the entire datastore and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. |
| | Secure hybrid network monitoring - Problem statement |
| |
|
This document describes a problem statement regarding the challenges and requirements for ensuring and monitoring the security status of networks operating in complex environments, such as hybrid or mixed cloud systems. |
| | Crawler best practices |
| |
|
This document describes best pratices for web crawlers. 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/garyillyes/cbcp. |
| | Automatic Minutes Generation |
| |
|
RFC 2418 requires that working group chairs ensure that sessions shall "be reported by making minutes available". Those minutes can be automatically generated from meeting recordings. This document requests that the IETF LLC update the meeting tooling to facilitate this. |
| | Verified Email Identity Framework (VEIF) |
| |
|
This document proposes the Verified Email Identity Framework (VEIF), a mechanism to ensure that every email address used for sending electronic mail is associated with a verifiable and accountable registrant. The goal is to significantly reduce spam, phishing, and identity abuse by introducing individual-level authentication in addition to existing domain-level controls such as SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489]. |
| | AGENTS.TXT: Strict Policy File for Automated Clients |
| |
|
This document specifies the AGENTS.TXT protocol, a strict plaintext policy file for automated clients, bots, and crawlers. It defines directives, top-line hash verification, optional parameters, and mandatory failure behavior for malformed files. Malformed files are treated as fully restrictive to prevent unintended access. |
| | Secure Hybrid Network Monitoring - Path Characteristics Service |
| |
|
"Secure hybrid network monitoring - Problem statement" identifies challenges in securing and monitoring networks deployed across hybrid and mixed cloud environments. This document introduces the Path Characteristics Service (PCS), a framework that enables applications and operators to obtain and evaluate verifiable information about the characteristics of the network paths they use. It outlines a non- normative architecture and interfaces for PCS and explains how PCS can help address the identified challenges; it does not define protocol requirements. |
| | Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants |
| |
| | draft-ietf-oauth-rfc7523bis-03.txt |
| | Date: |
07/10/2025 |
| | Authors: |
Michael Jones, Brian Campbell, Chuck Mortimore, Filip Skokan |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification updates the requirements for audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. |
| | A YANG Data Model and RADIUS Extension for Policy-based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-09.txt |
| | Date: |
07/10/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. |
| | 464XLAT Customer-side Translator (CLAT): Node Recommendations |
| |
|
464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates Requirements for IPv6 Customer Edge Routers to Support IPv4-as- a-Service [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions. |
| |
|
| |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-22.txt |
| | Date: |
06/10/2025 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-19.txt |
| | Date: |
06/10/2025 |
| | Authors: |
Pradosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document specifies a type of BGP Extended Community that enables routers to perform weighted load-balancing in multipath scenarios. |
| | Use of Variable-Length Output Pseudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFCs 5723, 6617, 6631, 7296, 8784, 9370 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. |
| | Separate Transports for IKE and ESP |
| |
|
The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. |
| | Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that aims to prevent some kinds of downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. |
| | A Network Data Model for Inventory Topology Mapping |
| |
|
This document defines a YANG data model to map the network inventory data with the topology data to form a base underlay network. The data model facilitates the correlation between the layer (e.g., Layer 2 or Layer 3) topology information and the inventory data of the underlay network for better service provisioning, network maintenance operations, and other assessment scenarios. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-22.txt |
| | Date: |
06/10/2025 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri, Padma Pillay-Esnault |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new Routing Locator encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. |
| | IS-IS YANG Model Augmentations for Additional Features - Release 1 |
| |
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. |
| | YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm |
| |
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also specifies the initial version of IANA-maintained YANG modules for IGP Algorithm Types and IGP Metric-Type. |
| | YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm |
| |
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. |
| | Registration of further IMAP/JMAP keywords and mailbox name attributes |
| |
|
This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It defines the intended use of these keywords and mailbox name attributes. This document registers all of these with IANA to avoid name collisions. |
| | Updated YANG Module Revision Handling |
| |
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. |
| | Registry policies "... with Expert Review" |
| |
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. To support its objectives for the period of time while the above updates have not yet been finalized, this document offers text that can be copy-pasted into specifications that want to make use of the augmented policies. // —— Editors' note: —— As to augmenting existing policies, the // provided proposals have been considered in // [I-D.baber-ianabis-rfc8126bis] within the IANABIS Working Group. // This topic is covered by Section 2 of our draft and there is a // placeholder "ADD NEW PROCEDURE" about it at Section 4 of // [I-D.baber-ianabis-rfc8126bis]. However, compared to our draft, // this is not augmenting the policy "IESG Approval". On the topic // of early registration covered by Section 3 of our draft, we were // under the impression that something similar could be argued about // it too, but not quite (yet). Looking at // [I-D.baber-ianabis-rfc7120bis], there seems to be no text or // placeholders on that topic yet. We expect such text to come in // the future, to ensure that the early allocation procedure is fully // specified also for registries that use the augmented policies. |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-stephan-green-use-cases-03.txt |
| | Date: |
06/10/2025 |
| | Authors: |
Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos |
| | Working Group: |
Individual Submissions (none) |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-use-cases |
| | Encrypted Authenticated Resource Locator |
| |
|
This document describes the Encrypted Authenticated Resource Locator (EARL) URI scheme and the encoding and decoding of the associated content data. An EARL is a bearer token that allows an encrypted data object to be located, decrypted and authenticated using a compact URI form designed for human readability. A range of work factors is supported from 2^112 to 2^252. The plaintext data format consists of an initial header section containing metadata describing the payload, the payload itself and an optional section containing signature data. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-05.txt |
| | Date: |
06/10/2025 |
| | Authors: |
Benoit Claise, Luis Contreras, Jan Lindblad, Marisol Amador, Emile Stephan, Qin WU |
| | Working Group: |
Individual Submissions (none) |
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network’s functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. |
| | A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel Support |
| |
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. |
| | vCon World Transcription Format Extension |
| |
|
This document defines the World Transcription Format (WTF) extension for Virtualized Conversations (vCon). The WTF extension provides a standardized analysis framework for representing speech-to-text transcription data from multiple providers within vCon containers. This extension defines a comprehensive analysis format that enables consistent transcription processing, quality assessment, and interoperability across different transcription services while preserving provider-specific features through extensible fields. The WTF extension is designed as a Compatible Extension that introduces a new analysis type for transcription data without altering existing vCon semantics, ensuring backward compatibility with existing vCon implementations. |
| | Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies how Classic McEliece Key Encapsulation Mechanism (KEM) is used to generate keys in the Internet Key Exchange version 2 (IKEv2) protocol. |
| | Data At Rest Envelope (DARE) |
| |
|
This document describes the Data At Rest Envelope (DARE) Envelope and Sequence. The DARE Envelope syntax is used to package plaintext or encrypted content payload and metadata with JOSE decryption and signature data authenticating the payload and metadata. The DARE Sequence format comprises a sequence of DARE Envelopes. The binary encoding of DARE envelopes allows compact encoding of encrypted and signed payloads of unknown length in a single pass with minimal overhead. The binary encoding of DARE sequences is designed to support an append only write mode and efficient reading in either the forwards or backwards directions. The JSON encoding of DARE Envelopes and sequences allows envelopes and sequences to be incorporated in other JSON objects. This document does not cover construction of indexes or signatures over multiple entries in a sequence. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of PCAP-related LinkType values and creates an IANA registry for those values. |
| |
|
| |
| | The AEGIS Family of Authenticated Encryption Algorithms |
| |
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. 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/cfrg/draft-irtf-cfrg-aegis-aead. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using IOAM data fields. |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-21.txt |
| | Date: |
05/10/2025 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of RATS conceptual messages (see Section 8 of [RFC9334], such as Evidence, Endorsements and Attestation Results, in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting attestation data to a Certification Authority. Including Evidence, Endorsements and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. |
| | The DNSCrypt Protocol |
| |
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation, providing a standardized approach to securing DNS communications. DNSCrypt improves confidentiality, integrity, and resistance to attacks affecting the original DNS protocol while maintaining compatibility with existing DNS infrastructure. |
| | FC-BGP Protocol Specification |
| |
|
This document defines an extension, Forwarding Commitment BGP (FC- BGP), to the Border Gateway Protocol (BGP). FC-BGP provides security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. Forwarding Commitment (FC) is a cryptographically signed segment to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in the BGP UPDATE message and alleviate route leaks in the BGP routing system. The extension is backward compatible, which means a router that supports the extension can interoperate with a router that doesn't support the extension. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS extension headers, including MPLS Network Action Sub-Stacks and Post-Stack Header, for HBH and E2E active measurements, for example, using IOAM data fields. |
| | A Historical Analysis of Design Lessons from The Reliable Data Protocol Version 1 and Version 2 |
| |
|
This document reviews and analyzes the history and experience of the Reliable Data Protocol. RDP was initially published as an experimental protocol in RFC 908 in 1984 and subsequently revised in RFC 1151 in 1991. RDP aimed to provide a message-oriented, reliable transport service to meet specific application requirements such as remote loading. This document summarizes the key technical experiences gained from RDP's experimental deployment, details the lessons learned regarding checksum performance and flow control mechanisms, and assesses the conceptual influence of its design principles on subsequent IETF transport protocols. The document is intended for historical archiving, providing a reference for early explorations of Internet transport protocols, and does not propose any new standards or deployment recommendations. |
| | Null Scheme for Signed Objects in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI). The Null Scheme is a niche signature scheme that can replace the redundant and costly use of actual digital signatures from so-called "one-time-use" key pairs in Signed Objects. The Null Scheme has as public key the digest of the message to be signed, and the signature is always empty. When a Null Scheme public key is the subject of a Signed Object's one-time- use End-Entity (EE) certificate, it establishes a secure binding between the issuer of the EE certificate and the message to be signed. This is cheaper in terms of size and verification time than using a real signature scheme, while providing the same security guarantees. |
| | The Meta-Layer: A Coordination Substrate for Presence,Annotation,and Governance on the Web |
| |
|
This document introduces the concept of a Meta-layer: a programmable coordination substrate that operates above content layers on the Internet. The Meta-layer enables communities, individuals, and agents to appear, annotate, and govern together in shared digital space, independent of underlying platforms. It is not a replacement for existing web or transport protocols, but a complementary infrastructure that integrates with them. The draft outlines the motivation, terminology, use cases, implementation model, risks, security considerations, and potential IANA registries for future work. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
| | draft-acme-device-attest-07.txt |
| | Date: |
03/10/2025 |
| | Authors: |
Brandon Weeks, Ganesh Mallaya, Sven Rajala |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-04.txt |
| | Date: |
03/10/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. 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-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-16.txt |
| | Date: |
03/10/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. The solution specified in this document addresses the requirements for In-stack network action and In-stack data found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". |
| | A Decent LISP Mapping System (LISP-Decent) |
| |
|
This draft describes how the LISP mapping system can be distributed for scale, decentralized for management and maintain trust among data-plane nodes. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other. |
| | A YANG Data Model for Microwave Radio Link |
| |
| | draft-ybam-rfc8561bis-03.txt |
| | Date: |
03/10/2025 |
| | Authors: |
Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. |
| | Enhanced Dynamic Capability for BGP |
| |
|
This document addresses the limitations with the BGP Dynamic Capability specification by introducing additional protocol extensions and operational procedures so that a BGP capability that requires bi-directional capability advertisement can be revised dynamically. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction, referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of residual bit error rate within the "Extra Padding" TLV of STAMP packets. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| | Certificate Renewal Recommendations for Enrollment over Secure Transport |
| |
|
This document describes an extension to RFC7030, Enrollment over Secure Transport to give an indication to a end-entity device when it should start attempting to renew its certificates. Prior art is that client decides, with a typical recommmendation to start when the remaining lifetime of the certificate is at the 50% point. As typical certificate lifetimes are reduced from years to fractions of a year, the 50% may be far too early, and this document provides a way to give alternate advice. |
| | AI URI Scheme |
| |
|
This document specifies the experimental ai Uniform Resource Identifier (URI) scheme. The scheme provides a dedicated access point for Artificial Intelligence (AI) resources, enabling autonomous systems and robots to connect natively while allowing human-facing applications to interoperate via HTTPS gateways. |
| | Unbound DATA Frames in HTTP/3 |
| |
|
This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a request or response stream, it indicates that all subsequent octets on that stream are interpreted as data. This applies both to message body data and to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived or indeterminate-length payloads. |
| | Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case |
| |
|
This document explores how existing IETF YANG data models, specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and Traffic Engineering (TE) topology data models, can be applied to support a use case involving dynamic AI model placement at Edge Cloud sites. The use case involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG data models to retrieve and request specific services objectives such as bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model applicability and identify gaps, if any. |
| | A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests |
| |
|
This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes. |
| | Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. |
| |
|
| |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
| | Partially Blind RSA Signatures |
| |
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) |
| |
| | draft-ietf-jose-hpke-encrypt-12.txt |
| | Date: |
02/10/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. |
| | Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New LISP use cases increase the amount of state that needs to be communicated and challenge the scalability of the system when using the UDP exchange. This document introduces the use of a reliable transport for ETR to Map-Server communications in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | An EAT Profile for Device Attestation |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust the device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be consumed by 3rd party attestation services external to the TVM, there is a need to standardise the representation of Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness |
| |
|
This document standardizes usage of Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) as identifiers to enable trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems (UAS) in Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). DETs can serve as Session IDs for privacy, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. |
| | The Transport Layer Security (TLS) Protocol Version 1.4 |
| |
|
This contribution has been withdrawn. |
| | Human Readable Validate ROA Payload Notation |
| |
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| | Human Readable ASPA Notation |
| |
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-mpls-00.txt |
| | Date: |
02/10/2025 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for SR-MPLS paths (including SR-MPLS Policies, SR-MPLS IGP best paths, and SR- MPLS IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SR-MPLS paths. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-srv6-00.txt |
| | Date: |
02/10/2025 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement for SRv6 using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SRv6 paths (including SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths. |
| | SSH Agent Protocol |
| |
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. |
| |
|
| |
| | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| | draft-ietf-bess-rfc8317bis-00.txt |
| | Date: |
01/10/2025 |
| | Authors: |
Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. |
| | Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) |
| |
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a TLS server. Bootstrapping devices have a public/private key pair, and this mechanism enables a TLS server to prove to the device that it knows the public key, and the device to prove to the TLS server that it knows the private key. The mechanism leverages existing Device Provisioning Protocol (DPP) and TLS standards and can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server. |
| | Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields for Intra-IOAM-Domain use cases. |
| | Clarification to processing Key Usage values during CRL validation |
| |
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-ietf-mpls-mna-ps-hdr-03.txt |
| | Date: |
01/10/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data specific requirements found in "RFC 9613". This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "RFC 9789". |
| | 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. |
| | Compact Routing Header (CRH) Helper Option |
| |
|
This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes. |
| | Email Feedback Reports for DKIM Signers |
| |
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. |
| | A method for describing changes made to an email |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. |
| | DKIM2 Header Definitions |
| |
|
This document describes the email header fields defined for DKIM2, and how they work togther to provide the required properties. This is an early draft, a work in progress. |
| | Making LocalRoot a Best Current Practice |
| |
|
RFC 8806 (often called "LocalRoot") defines a mechanism whereby a recursive resolver can fetch the contents of an entire zone and place this information into the resolver's cache. This has several benefits, including increased reliability, increased performance, improved privacy, and decreased or mitigation of the effect of some types of DoS attacks. While the majority of DNS resolver implementations natively support RFC 8806, it remains tricky to configure and maintain. This document recommends that DNS resolver software simplify this configuration, and further suggests that configuration becomes the default. This document updates Section 2 of RFC8806 by relaxing the requirement that implementations MUST run an authoritative service. /* Ed (WK): Open questions / ToDo / Notes (to be removed before publication): |
| | Vocabulary For Expressing Content Signals |
| |
|
This Internet Draft proposes three categories that would enable parties to express preferences regarding how digital assets are used by automated processing systems. The proposal is for these categories to nest within the larger category of Automated Processing, currently envisaged in the [AIPREF-VOCAB]. |
| | Applicability of TCP-AO for Securing NETCONF and gNMI |
| |
|
This document analyzes the applicability of the TCP Authentication Option (TCP-AO) to secure TCP-based network management protocols, specifically NETCONF and gNMI. It describes deployment profiles in which TCP-AO provides per-connection integrity and peer authentication with low operational overhead, either as an alternative to or in combination with TLS/SSH. This document gives guidance on key management (e.g., static keys and operational "key chains") and documents expected behaviors and benefits. No new protocol bits are defined and there are no IANA actions. |
| | Quantum FWM Control Protocol (QFCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qfcp-00.txt |
| | Date: |
01/10/2025 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Four-Wave Mixing Control Protocol (QFCP), a lightweight transport protocol designed to operate over UDP in IP optical environments. QFCP enables the transmission of control- plane parameters required for quantum four-wave mixing (FWM) processes and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | Route Server Next Hop Translation |
| |
|
With the advent of RFC8950, Internet Exchang Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document updates RFC 6890 by registering a special-purpose address, and RFC 7947 by specifying an allowed route modification at the route server. |
| | Semantic Inference Routing Protocol (SIRP) |
| |
|
This document specifies the Semantic Inference Routing Protocol (SIRP), a framework for content-level classification and semantic routing in AI inference systems. By analyzing the content of inference requests--rather than relying solely on client-supplied metadata--SIRP enables routing decisions that are more robust, consistent, and extensible. SIRP also defines optional value-added routing (VAR) extensions for cost optimization, urgency prioritization, domain specialization, and privacy-aware handling. |
| | Concise Selector for Endorsements and Reference Values |
| |
| | draft-ietf-rats-coserv-01.txt |
| | Date: |
01/10/2025 |
| | Authors: |
Paul Howard, Thomas Fossati, Henk Birkholz, Shefali Kamal, Giridhar Mandyam, Ding Ma |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-24.txt |
| | Date: |
01/10/2025 |
| | Authors: |
Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for Internet transports that enables fast startup of congestion control for a wide range of connections, known as "Careful Resume". It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the congestion control behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of this method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |