| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It further clarifies the unconditional requirement for implementing Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. |
| | IPv6 Node Requirements |
| |
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. |
| | Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| | draft-ietf-ace-edhoc-oscore-profile-08.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. |
| | Protecting EST Payloads with OSCORE |
| |
| | draft-ietf-ace-coap-est-oscore-08.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. |
| | Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager |
| |
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. |
| | Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (4) It extends the error handling at the AS, for which it defines a new error code. (5) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (6) It amends two of the requirements on profiles of the framework. |
| | Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. |
| | BRSKI discovery and variations |
| |
|
This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators, especially in the face of variations in the protocols that can introduce non-interoperability when not equally supported by both responder and initiator. This document does not define any new discovery methods. Instead, it solves the challenges of announcing, discovering and selecting an interoperable instance of a BRSKI responder by defining a data model and simple string based encoding for BRSKI variations and by prescribing how to encode this encoding of variations into multiple pre-existing discovery mechanisms: DNS-SD, GRASP and CoAP discovery (CORE-LF). This document also defines the procedures necessary for interoperable announcement, discovery and selection in the face of redundant responder, making deployment more resilient by allowing easy and automatic redundancy. BRSKI Proxies are a core element of BRSKI. This document specifies how Proxies need to be implemented to support proxying of BRSKI variations, even supporting possible future variations not in existance when the proxy was implemented. Finally, this document defines the IANA registrities to track the definition of variations and their encoding and hence allow easy introduction of new variations, support of additional discovery protocols and even discovery of additional BRKI roles (such as MASA). All with no or minimum additional specification requirements other than new registry entries. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-09.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices, as well as a CBOR-based publish-subscribe interface for streaming data. The described interfaces are extensible. The specification also defines a protocol mapping function to to map this interface to commonly used non-IP protocols. |
| | Per multicast flow Designated Forwarder Election for EVPN |
| |
|
This document defines an enhancement to the Designated Forwarder (DF) election process in Ethernet Virtual Private Network (EVPN) environments. While traditional DF election operates at a per Virtual Local Area Network (VLAN) or per group of VLANs (in case of VLAN bundle or VLAN-aware bundle service) level, such granularity may not be sufficient for applications requiring optimized or isolated multicast forwarding. This specification introduces a refined DF election mechanism that extends existing hash-based methods to operate at a more granular level specifically at the tuple of Ethernet Segment Identifier (ESI), VLAN, and multicast flow. This approach enables improved traffic distribution, enhanced load balancing, and greater deployment flexibility for multicast delivery in EVPN based networks. The proposed method is designed to remain compatible with existing DF election procedures while offering targeted improvements for multicast scenarios. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-14.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Rishabh Parekh, Dan Voyer, Clarence Filsfils, Mankamana Mishra, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | AC-Aware Bundling Service Interface in EVPN |
| |
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. |
| | Weighted HRW and its applications |
| |
|
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. |
| | Multiple Loss Ratio Search |
| |
|
This document specifies extensions to "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and improve result repeatability and comparability. MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software- based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs purpose-built ASIC / NPU / FPGA hardware. |
| | Task Extensions to iCalendar |
| |
|
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has seen limited adoption and use, mainly for personal reminders and to-do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, a named subsets of JSContact elements that are supported in context of a contact data exchange protocol or other use case. It aims to facilitate using JSContact in contexts where supporting all of JSContact semantics is not appropriate. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-11.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes. |
| | CATS Metrics Definition |
| |
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from the computing domain used for CATS. |
| | Packed CBOR |
| |
| | draft-ietf-cbor-packed-16.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Carsten Bormann, Mikolai Guetschow |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -16 is intended as input to IETF 123, to address the // discussion about the use of simple values as reference items // during the 2025-06-11 CBOR interim meeting. It contains a number // of editorial improvements as well as the new concept of an // integration tag; it is for discussion whether the latter should or // should not be added to Packed CBOR. The wording of the present // revision continues to make use of the tunables A/B/C to be set to // specific numbers before completing the Packed CBOR specification; // not all the examples may fully align yet. |
| | CBOR Extended Diagnostic Notation (EDN) |
| |
|
This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -18 // corrects a few omissions from -17; it is not intended to make // technical changes from -17. It is intended for use as an input // document for the CBOR WG meeting at IETF 123. |
| | CBOR Common Deterministic Encoding (CDE) |
| |
| | draft-ietf-cbor-cde-12.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document documents the Best Current Practice for CBOR Common Deterministic Encoding (CDE), which can be shared by a large set of applications with potentially diverging detailed requirements. It also defines the term "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. |
| | A YANG data model to manage configurable DWDM optical interfaces |
| |
| | draft-ietf-ccamp-dwdm-if-param-yang-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) [ITU-T_G.698.2] or any other ITU-T recommendation. Use cases are described in [RFC7698]. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of DWDM interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. |
| | 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. |
| | Conveying Transceiver-Related Information within RSVP-TE Signaling |
| |
| | draft-ietf-ccamp-tsvmode-signaling-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Julien Meuric, Esther Le Rouzic, Gabriele Galimberti, Sergio Belotti, Dieter Beller |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. |
| | BBR Congestion Control |
| |
| | draft-ietf-ccwg-bbr-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Neal Cardwell, Ian Swett, Joseph Beshay |
| | Working Group: |
Congestion Control Working Group (ccwg) |
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. |
| | 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. |
| | CDNI Logging Extensions |
| |
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. |
| | Content Delivery Network Interconnection (CDNI) Named Footprints |
| |
|
The document specifies an object-based semantics to CDNI footprint advertisement, that enables RESTful implementations of the FCI protocol. This approach enables multiple CDNI capabilities within the FCI to share common footprint definitions and allows footprint advertisement to be used in additional CDNI interfaces. This document further specifies operational enhancements to the CDNI footprint support. The document specifies an alternative, object-based approach to CDNI footprint advertisement, that enables RESTful implementations of the FCI protocol. This approach enables multiple CDNI capabilities within the FCI to share common footprint definitions and allows footprint advertisement to be used in additional CDNI interfaces. This document further specifies operational enhancements to the CDNI footprint support. |
| | The BBS Signature Scheme |
| |
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. |
| | Guidelines for Writing Cryptography Specifications |
| |
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a traditional cryptographic component and a post-quantum (PQ) KEM. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. |
| | Concrete Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. |
| | Constrained Resource Identifiers |
| |
| | draft-ietf-core-href-23.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Carsten Bormann, Henk Birkholz |
| | Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –23 attempts to address the AD review comments; // it is submitted right before the I-D deadline in order to serve as // discussion input to IETF 123 even though not all discussions have // completed. In particular, the updated handling of zone // identifiers requires some additional scrutiny. |
| | Observe Notifications as CoAP Multicast Responses |
| |
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. |
| | Key Update for OSCORE (KUDOS) |
| |
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. |
| | CoAP Transport Indication |
| |
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-16.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| | Key Usage Limits for OSCORE |
| |
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. |
| | Identifier Update for OSCORE |
| |
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-15.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). 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 COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. |
| | ML-DSA for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
DNS Delegation (deleg) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation of the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | Reliable and Available Wireless Architecture |
| |
|
Reliable and Available Wireless (RAW) extends the reliability and availability of DetNet to networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet Service sub-layer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. |
| | Domain Control Validation using DNS |
| |
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | Clarifications on CDS/CDNSKEY and CSYNC Consistency |
| |
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, RFC 7344 provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) can query these records from the child and, after validation, use them to update the parent-side RRsets of the delegation. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. |
| | DNS Multiple QTYPEs |
| |
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). |
| | Extensible Authentication Protocol (EAP) Using Privacy Pass Token |
| |
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. |
| | 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. |
| | AS Path Prepending |
| |
| | draft-ietf-grow-as-path-prepending-16.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Mike McBride, Doug Madory, Jeff Tantsura, Robert Raszuk, Hongwei Li, Jakob Heitz, Gyan Mishra |
| | Working Group: |
Global Routing Operations (grow) |
|
Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet. |
| | Byte Range PATCH |
| |
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, facilitating random access writes and segmented uploads of resources. |
| | The HTTP Wrap Up Capsule |
| |
|
HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Prodosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. |
| | ICMP Extension Header Length Field |
| |
|
The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. This document UPDATES RFC 4884. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | Terminology for Constrained-Node Networks |
| |
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. |
| | Responsiveness under Working Conditions |
| |
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. |
| | Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-08.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. |
| | The Role of the Internet Research Task Force (IRTF) |
| |
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This document is a product of the Internet Research Steering Group (IRSG). |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for 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 Data Model for Network Inventory Location |
| |
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. |
| | 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. |
| | JSON Proof Token and CBOR Proof Token |
| |
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. |
| | JSON Web Proof |
| |
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay. |
| | JSON Proof Algorithms |
| |
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) |
| |
| | draft-ietf-jose-hpke-encrypt-11.txt |
| | Date: |
07/07/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. |
| | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) |
| |
| | draft-ietf-lake-authz-05.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, In order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. |
| | EDHOC Authenticated with Pre-Shared Keys (PSK) |
| |
| | draft-ietf-lake-edhoc-psk-04.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Elsa, Goeran Selander, John Mattsson, Rafael Marin-Lopez |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations. |
| | Remote attestation over EDHOC |
| |
| | draft-ietf-lake-ra-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Yuxuan Song, Goeran Selander |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-20.txt |
| | Date: |
07/07/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 Evidence 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 Evidence to a Certification Authority. Including Evidence 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. |
| | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
| |
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-07.txt |
| | Date: |
07/07/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 security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application 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. |
| | Unsigned X.509 Certificates |
| |
|
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. |
| | A Mechanism for X.509 Certificate Discovery |
| |
| | draft-ietf-lamps-certdiscovery-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether to fetch the Secondary Certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of Primary Certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. |
| | 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. |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-23.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Alvaro Retana, Dino Farinacci, David Meyer, Job Snijders |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. |
| | Interoperable Email Addresses for SMTPUTF8 |
| |
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding elements that harm human-to-human interoperation. This is one of a pair of documents: this contains recommendations for what addresses humans should use, such that address provisioning systems can restrain themselves to addresses that email valdidators accept. (This set can also be described in other ways, including "simple to cut-and-paste" and "understandable by some community".) Its companion defines simpler rules, accepts more addresses, and is intended for software like MTAs. |
| | SMTPUTF8 address syntax |
| |
|
This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. This is one of a pair of documents: This is simple to implement, contains only globally viable rules and is intended to be usable for software such an MTA. Its companion defines has more complex rules, takes regional usage into account and aims to allow only addresses that are readable and cut-and-pastable in some community. |
| | QUIC-Aware Proxying Using HTTP |
| |
| | draft-ietf-masque-quic-proxy-06.txt |
| | Date: |
07/07/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. |
| | DNS Configuration for Proxying IP in HTTP |
| |
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. |
| | YANG Data Model for Automatic Multicast Tunneling |
| |
| | draft-ietf-mboned-amt-yang-04.txt |
| | Date: |
07/07/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. |
| | More Instant Messaging Interoperability (MIMI) message content |
| |
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-04.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| | Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| | Deep Audio Redundancy (DRED) Extension for the Opus Codec |
| |
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. |
| | ML-KEM and Hybrid Cipher Suites for Messaging Layer Security |
| |
| | draft-mahy-mls-pq-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Rohan Mahy, Richard Barnes |
| | Working Group: |
Messaging Layer Security (mls) |
|
This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. |
| | Network Overlay Impacts to Streaming Video |
| |
|
This document examines the operational impacts to streaming video applications caused by changes to network policies by network overlays. The network policy changes include IP address assignment, transport protocols, routing, and DNS resolvers, which in turn affect a variety of important content delivery aspects such as latency, CDN cache selection, delivery path choices, traffic classification and content access controls. |
| | Media over QUIC Transport |
| |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Low Overhead Media Container |
| |
| | draft-ietf-moq-loc-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Mo Zanaty, Suhas Nandakumar, Peter Thatcher |
| | Working Group: |
Media Over QUIC (moq) |
|
This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the WARP streaming specification, which defines a catalog format for publishers to annouce and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. |
| | YANG Data Model for MPLS mLDP |
| |
| | draft-ietf-mpls-mldp-yang-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | YANG Packages |
| |
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) |
| |
|
DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. |
| | Trusted Path Routing |
| |
|
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-14.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an alternative experimental approach for the application of the Alternate-Marking Method to SRv6. It uses a new TLV in the Segment Routing Header (SRH) with experimental code points, and thus participation in this experiment should be between coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343 and the scope of the experiment is to determine whether those are significant and attractive to the community. This protocol extension has been developed outside the IETF as an alternative to the IETF’s standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. Researchers are invited to submit their evaluations of this work to the RFC Editor for consideration as independent submissions or to the IETF SPRING working group as Internet-Drafts. |
| | Carrying NRP related Information in MPLS Packets |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Multiple NRPs can be created by network operator to meet the diverse requirements of different enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used as the NRP Selector to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the NRP Selector ID and related information in MPLS packets. The procedure for processing the NRP Selector ID and related information is also specified. |
| | Encoding Network Slice Identification for SRv6 |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. |
| | Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP |
| |
|
This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. |
| | Updated Rules for PCE Communication Protocol (PCEP) Object Ordering |
| |
|
The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these messages are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. |
| | Additional addresses for QUIC |
| |
|
This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. |
| | Template-Driven HTTP Request Proxying |
| |
|
HTTP request proxying behaviors have long been part of the core HTTP specification. However, the core request proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative proxy service configuration for HTTP requests. The proxy service is identified by a URI Template, similarly to "connect-tcp" and "connect-udp". |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-14.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | NTRU Key Encapsulation |
| |
| | draft-fluhrer-cfrg-ntru-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Scott Fluhrer, Michael Prorock, Sofia Celi, John Gray, Xagawa Keita, Haruhisa Kosuge |
| | Working Group: |
Individual Submissions (none) |
|
This draft document provides recommendations for the implementation of a post-quantum Key Encapsulation Mechanism (KEM) scheme based on the NTRU encryption scheme. The KEM is an existing cryptographic system; no new cryptography is defined herein. The well-defined and reviewed parameter sets for the scheme are defined and recommended. The test vectors are also provided. |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | Managing CBOR codepoints in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | EVPN Inter-Domain Option-B Solution |
| |
|
An EVPN Inter-Domain interconnect solution is required when two or more sites of the same Ethernet Virtual Private Network (EVPN) are connected to different IGP domains or Autonomous Systems (AS) and need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for this type of EVPN connectivity. While multiple documents describe aspects of this interconnect approach, there is no single document that summarizes the impact of Inter-Domain Option-B connectivity on EVPN procedures. This document does not define new procedures; rather, it analyzes the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the issues identified. These solutions are either based on existing specifications or rely on local implementations that do not modify the end-to-end EVPN control plane. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | BFD Path Consistency over SR |
| |
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy |
| | Purge Originator Identification for OSPF |
| |
|
In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Using onion routing with CoAP |
| |
|
The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and of clients similar to how Tor (onion routing) enables it for TCP-based protocols. |
| | Multiple Algorithm Rules in DNSSEC |
| |
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. |
| | Deterministic Networking (DetNet) Data Plane - Flow interleaving for scaling detnet data planes with minimal end-to-end latency and large number of flows. |
| |
|
This memo explain requirements, benefits and feasibility of a new DetNet service function tentatively called "flow interleaving". It proposes to introduce this service function into the DetNet architecture. Flow interleaving can be understood as a DetNet equivalent of the IEEE TSN timed gates. Its primary role is intended to be at the ingress edge of DetNet domains supporting higher utilization and lower bounded latency for flow aggregation (interleaving of flows into a single flow), as well as higher utilization and lower bounded latency for interleaving occurring in transit hops of the DetNet domain in conjunction with in-time per-hop bounded latency forwarding mechanisms. |
| | Data Generation and Optimization for Network Digital Twin |
| |
|
Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network in various what-if scenarios. Recently, Artificial Intelligence (AI) models, especially neural networks, have been applied for NDT modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model quality from the data perspective. |
| | AI-Based Distributed Processing Automation in Network Digital Twin |
| |
| | draft-oh-nmrg-ai-adp-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Oh Seokbeom, Yong-Geun Hong, Joo-Sang Youn, Hyunjeong Lee, Seung-Woo Hong, Hyun-Kook Kahng |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the use of AI technology and digital twin technology to automate the management of computer network resources distributed across different locations. Digital twin technology involves creating a virtual model of real-world physical objects or processes, which is utilized to analyze and optimize complex systems. In a network digital twin, AI-based network management by automating distributed processing involves utilizing deep learning algorithms to analyze network traffic, identify potential issues, and take proactive measures to prevent or mitigate those issues. Network administrators can efficiently manage and optimize their networks, thereby improving network performance and reliability. AI-based network management, utilizing network digital twin technology, also aids in optimizing network performance by identifying bottlenecks in the network and automatically adjusting network settings to enhance throughput and reduce latency. By implementing AI-based network management through automated distributed processing, organizations can improve network performance, and reduce the need for manual network management tasks. |
| | Advertise NRP Group extensions for IGP |
| |
|
Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes,structures, and functions so that each slice can be dedicated to specific services or customers. A Network Resource Partition (NRP) is a collection of resources in the underlay network. Each NRP is used as the underlay network construct to support one or a group of IETF network slice services. This document describes an IGP mechanism that is used to advertise a large number of NRPs into a smaller number of NRP groups. |
| | EVPN Anycast Multi-Homing |
| |
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function supports load balancing of unicast traffic from remote Network Virtualization Edge (NVE) devices to NVEs that are multi-homed to the same CE, regardless of whether the CE’s MAC/IP information has been learned on all those NVEs. This document introduces an optional enhancement to the EVPN multi-homing Aliasing function, referred to as EVPN Anycast Multi- homing. This optimization is specific to EVPN deployments over NVO3 tunnels (i.e., IP-based tunnels) and may offer benefits in typical data center designs, which are discussed herein. |
| | MIMI Portability |
| |
|
This document describes MIMI Portability mechanisms. |
| | MIMI Attachments |
| |
|
This document describes MIMI Attachments. |
| | Considerations For Maintaining Protocols Using Grease and Variability |
| |
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. |
| | Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies |
| |
|
The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. |
| | SCION Data Plane |
| |
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION Data Plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Classic McEliece |
| |
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. 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-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. |
| | Enhanced Use Cases for Scaling Deterministic Networks |
| |
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video, intelligent computing, and ISAC-enabled smart factory and outlines the common properties implied by these use cases. |
| | Opportunistic TCP-AO with TLS |
| |
| | draft-piraux-tcp-ao-tls-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. |
| | BGP over TLS/TCP |
| |
|
This document specifies the utilization of TCP/TLS to support BGP. |
| | Datagram Transport Layer Security (DTLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines a key-management solution based on Datagram Transport Layer Security 1.3 (DTLS) to protect the content of Stream Control Transmission Protocol (SCTP) packets using the packet protection framework provided by the SCTP DTLS chunk. The combination provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re-authentication and rekeying with ephemeral key exchange. The key-management solution does not require any additional defined features or implementation support beyond core DTLS 1.3. This is intended as a replacement to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| | MLS Virtual Clients |
| |
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. |
| | X-Wing: general-purpose hybrid post-quantum KEM |
| |
|
This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. |
| | Bicone Source Address Validation |
| |
|
The primary design goal of source address validation (SAV) is avoiding improper blocks (i.e., blocking legitimate traffic) while maintaining directionality (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) for an Autonomous System (AS) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter which contains prefixes exclusively belonging to the provider cone. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. |
| | Characterization and Benchmarking Methodology for Power in Networking Devices |
| |
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. |
| | The Asynchronous Remote Key Generation (ARKG) algorithm |
| |
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. |
| | Discovery of Network-designated OSCORE-based Resolvers: Problem Statement |
| |
| | draft-lenders-core-dnr-06.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. |
| | Applicability of GMPLS and PCEP for fine grain Optical Transport Network |
| |
|
ITU-T Recommendation ITU-T G.709/Y.1331 (2020) Amd.3 (03/2024) introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. |
| | Compute-Aware Traffic Steering for Midhaul Networks |
| |
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. This document described the usage of Computing-Aware Traffic Steering (CATS) within Midhaul (MH) networks in the O-RAN architecture. It details how CATS can enhance traffic steering decisions between Distributed Units (DUs) and Centralized Units (CUs) by considering both compute resource metrics (e.g., CPU and memory utilization of CU instances) and network performance metrics (e.g., bandwidth, latency, reliability). The document discusses the integration of CATS with O-RAN management frameworks, and the interplay with the Transport Network Manager (TNM) in O-RAN using standard interfaces defined by IETF (as for example the one for Network Slice Services for connectivity provisioning). |
| | Self-Clocked Rate Adaptation for Multimedia |
| |
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. This specification obsoletes RFC 8298. |
| | PQ/T Hybrid KEM: HPKE with JOSE/COSE |
| |
|
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. |
| | Filtering Out RPKI Data by Type based on Enhanced SLURM Filters |
| |
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. |
| | VESPER - Framework for VErifiable STI Personas |
| |
|
This document formalizes a profile and a framework for the use of delegate certificates and authority tokens to strengthen the association between telephone number assignments and the entities that have the authoritative right to use them. It defines a model in which the TNAuthList Authority Token serves as a trusted representation of telephone number assignment and right-to-use (RTU), anchored by a Notary Agent that logs these associations through verifiable transparency mechanisms. The framework also extends the use of authority tokens to support other PASSporT claims like Rich Call Data (RCD) by defining a role for JWTClaimConstraints Authority Tokens. These tokens are issued by authoritative or recognized and vetted claim agents within the ecosystem to assert information associated with the entity assigned a telephone number. The Notary Agent plays a critical role in recording these claims and their provenance, enhancing transparency and accountability. Delegate certificates encapsulate and incorporate both the telephone number and associated information validated via authority tokens to the certification authority issuing them, binding them to the authenticated telephone number of the calling party. These certificates are published to a certificate transparency log, enabling relying parties to independently verify the integrity and legitimacy of number use and related claims. The VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and the ACME authority token to formalizing a verifiable, auditable, and privacy-conscious foundation for associating telephone numbers with vetted entities and validated assertion of associated metadata. |
| | IGP Extensions for Optimized SRv6 SID Advertisement |
| |
|
When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance. |
| | Attester Groups for Remote Attestation |
| |
|
This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. |
| | Pacing in Transport Protocols |
| |
| | draft-welzl-iccrg-pacing-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | Logging over Media over QUIC Transport |
| |
|
Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. |
| | PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters |
| |
|
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. |
| | SLAAC Prefixes with Variable Interface ID (IID) Problem Statement |
| |
|
In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. |
| | SLAAC Prefixes with Variable Interface ID (IID) |
| |
|
This draft proposes the use of a longer prefixes in PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits. This would eliminate the race to the bottom concerns. This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. |
| | Mobile Traffic Steering |
| |
| | draft-liebsch-dmm-mts-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Individual Submissions (none) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | SRv6 Inter Domain Routing |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | On Numbers in CBOR |
| |
|
The Concise Binary Object Representation (CBOR), as defined in STD 94 (RFC 8949), is a data representation format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. Among the kinds of data that a data representation format needs to be able to carry, numbers have a prominent role, but also have inherent complexity that needs attention from protocol designers and implementers of CBOR libraries and of the applications that use them. This document gives an overview over number formats available in CBOR and some notable CBOR tags registered, and it attempts to provide information about opportunities and potential pitfalls of these number formats. // This is a rather drafty initial revision, pieced together from // various components, so it has a higher level of redundancy than // ultimately desired. |
| | IS-IS Extension for Big TLV |
| |
|
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a solution to IS-IS extension for encoding the TLV whose value is bigger than 255 octets. |
| | Domain variant support for EPP |
| |
|
This document defines an EPP extension allowing clients to learn about and manipulate variant groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant. |
| | Current State of the Art for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Networks (HP-WANs) represent a critical infrastructure for the modern global research and education community, facilitating collaboration across national and international boundaries. These networks, such as Janet, ESnet, GÉANT, Internet2, CANARIE, and others, are designed to support the general needs of the research and education users they serve but also the the transmission of vast amounts of data generated by scientific research, high-performance computing, distributed AI-training and large-scale simulations. This document provides an overview of the terminology and techniques used for existing HP-WANS. It also explores the technological advancements, operational tools, and future directions for HP-WANs, emphasising their role in enabling cutting-edge scientific research, big data analysis, AI training and massive industrial data analysis. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
This document specifies an extension to the ACME protocol [RFC8555] that enables Acme server to use the public key authentication protocol to verify that the real certificate applicant behind the Acme client has control over the identity and to ensure strong consistency between the identity in the challenge phase and the identity of the final certificate issued. This document also proposes a process extension for removing CSR at the certificate application phase. |
| | Terminology for Energy Efficiency Network Management |
| |
|
Energy-efficient network management is primary meant to enhance conventional network management with energy-related management capabilities to optimize the overall energy consumption at the level of a network. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network element and their components. This document is defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various Label Switched Path (LSP) identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. |
| | Designated Verifier Signatures for JOSE |
| |
| | draft-bastian-jose-dvs-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Paul Bastian, Micha Kraus, Stefan Santesson, Peter Altmann |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines structures and algorithm descriptions for the use of designated verifier signatures, based on a combination of Key Agreement and Message Authentication Code, with JOSE. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network or Intent-based Networking, and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. |
| | Serialization of MoQ Objects to Files |
| |
|
This specification provides a way to save the metadata about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the metadata and payload data allows the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to clients. |
| | Applicability of TVR YANG Data Models |
| |
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include resource preservation networks, operating efficiency networks and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. |
| | Calibration of Measured Time Values between Network Elements |
| |
|
Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. To ensure consistency and accuracy across different network element implementations, a benchmarking procedure is necessary to calibrate the timestamps. Such a procedure can permit the identification and correction of any deviations or biases in the time stamps produced by diverse devices. This document proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. |
| | Flexicast QUIC: combining unicast and multicast in a single QUIC connection |
| |
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. |
| | DHCPv4 Option for IPv4 routes with IPv6 nexthops |
| |
|
As a result of the shortage of IPv4 addresses, installations are increasingly recovering IPv4 addresses from uses where they are not strictly necessary. One such situation is in establishing next hops for IPv4 routes, replacing this use with IPv6 addresses. This document describes how to provision DHCP-configured hosts with their routes in such a situation. // This draft lives at https://github.com/eqvinox/dhc-route4via6 |
| | A YANG Data Model for Passive Network Inventory |
| |
| | draft-ygb-ivy-passive-network-inventory-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Chaode Yu, Aihua Guo, Italo Busi, Mohammad Boroon, Sergio Belotti, tom van caenegem, Swaminathan S., Swaminathan B., Nigel Davis, Mauro Tilocca, Brad Peters, Bin Yoon, liuyucong, Yang Zhao, Avinash Sakalabhaktula |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a YANG data model for tracking and managing passive network inventory. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-green-api-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Alejandro Muniz, Marisol Amador, Fernando Munoz, Jan Lindblad |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | A Password Authenticated Key Exchange Extension for TLS 1.3 |
| |
| | draft-bmw-tls-pake13-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Laura Bauman, David Benjamin, Samir Menon, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) ) |
| |
|
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based authentication of DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. |
| | SRv6 Inter Domain Routing Architecture |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | SRv6 Inter Domain Routing Use Cases |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | 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. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| | Controlling IP Fragmentation on Common Platforms |
| |
|
When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. |
| | Scalable Quality Extension for the Opus Codec (Opus HD) |
| |
|
This document updates RFC6716 to add support for a scalable quality layer. |
| | 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. 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. |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-stephan-green-use-cases-02.txt |
| | Date: |
07/07/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 |
| | Lightweight Secure Shell (SSH) Signature Format |
| |
|
This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. |
| | Split signing algorithms for COSE |
| |
|
This specification defines COSE algorithm identifiers used when one signing operation is split between two cooperating parties. When performing split signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited-bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. |
| | Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI. |
| | Interactive Sigma Proofs |
| |
|
This document describes interactive sigma protocols, a class of secure, general-purpose zero-knowledge proofs of knowledge consisting of three moves: commitment, challenge, and response. Concretely, the protocol allows one to prove knowledge of a secret witness without revealing any information about it. |
| | Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | SRv6 Policy SID List Optimization Advertisement |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a BGP-LS extension to indicate whether the endpoint's node SID is included or excluded in installing SID list(s) of the Candidate Path (CP) of an SRv6 policy. |
| | An Architecture for IP in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-24 minutes) and intermittent communications, because of orbital dynamics. The IP protocol stack used on Earth's Internet is based on assumptions of shorter delays and mostly uninterrupted communications. This document describes the architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configuration and application protocol timers. This architecture applies to the Moon, Mars, or general interplanetary networking. |
| | A Public Key Service Provider for Verification in Multiple Issuers and Verifiers |
| |
|
SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure. |
| | JWTClaimConstraints profile of ACME Authority Token |
| |
|
This document defines an authority token profile for handling the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. This profile follows the model established in Authority Token for the validation of TNAuthList but is specifically tailored for the JWTClaimConstraints certificate extensions. The profile enables validation and challenge processes necessary to support certificates containing both TNAuthList and JWTClaimConstraints, particularly in the context of Secure Telephone Identity (STI). |
| | Requirements Analysis of System and Network for Large Language Model Inference Service |
| |
|
With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, such as vLLM, SGLang, Mooncake, etc. This paper investigates mainstream inference frameworks, summarizes their core design principle and research question, and analyzes the challenges and requirements they impose on network management. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. |
| | Large Model based Agents for Network Operation and Maintenance |
| |
|
Current advancements in AI technologies, particularly large models, have demonstrated immense potential in content generation, reasoning, analysis and so on, providing robust technical support for network automation and self-intelligence. However, in practical network operations, challenges such as system isolation and fragmented data lead to extensive manual, repetitive, and inefficient tasks, the improvement of intelligence level is very necessary. This document identifies typical scenarios requiring enhanced intelligence, and explains how AI Agents and large model technologies can empower networks to address operational pain points, reduce manual efforts, and explore impacts on network data, system architectures, and interfaces correspondingly. It further explores and summarizes standardization efforts in implementation. |
| | Remote Attestation with Multiple Verifiers |
| |
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. 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/ietf-rats/draft-deshpande-multi-verifier. |
| | YANG Datastore Telemetry (YANG Push Lite) |
| |
|
YANG Push Lite is a YANG datastore telemetry solution, as an alternative specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. |
| | KEM based Authentication for the IKEv2 with Post-quantum Security |
| |
|
This draft specifies a new authentication mechanism, called KEM based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. This is motivated by the fact that ML-KEM is much more efficient that ML-DSA, which are the post-quantum algoirhtms for mitigating the pontential security threats again quantum computers. The KEM based authenticationth for the IKV2 is achieved via introduing a new value of the IKEv2 Authentication Method registry mantained by IANA. For using the new authentication method, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined by [RFC9593]，to negotiate the supported KEM algorithms. After that, the correponding KEM certificates and cipthertext are exchanged via the INTERMEDIATE Exchange. Finally，the IKE messages are authenticated via the shared secret encapsulated between the two peers. This documents also specifies the instantiation with ML-KEM for this new general authenticaiton method for the IKEv2. [EDNOTE: Code points for KEM-based authentication may need to be assigned in the IKEv2 Authenticaion Method registry, maintained by IANA] |
| | YANG Data Model for supporting multipath IGMP/MLD proxies |
| |
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. |
| | Multipath Traffic Engineering |
| |
| | draft-kompella-teas-mpte-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Kireeti Kompella, Luay Jalil, Mazen Khaddam, Andy Smith |
| | Working Group: |
Individual Submissions (none) |
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, nor the load balancing equally weighted to each next hop. Moreover, the desired destination may be reachable via multiple egresses. The proposal includes a protocol for signaling MPTE paths using various types of tunnels, some of which are better suited to multipathing. |
| | 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. |
| | A YANG Module for Entitlement Inventory |
| |
|
This document proposes a YANG module for incorporating entitlements in a network inventory of entitlements. 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. |
| | Proposal for experimentation with stateless IPv6 multicast source routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing Headers (MRH) |
| |
|
This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/ SRv6 networks as well as BIER networks as a related effort. |
| | Secure Asset Transfer Protocol (SATP) Implementation Guide |
| |
|
This memo provides guidelines to developers of gateway systems, digital asset networks and client applications for the Secure Asset Transfer Protocol (SATP). Multiple gateways can represent the same digital asset network following the SATP standards, which necessitate basic implementation guidelines as outlined in this document. It also serves as an introduction to the SATP processing workflow for those new to the SATP standards. |
| | MoQT Test |
| |
|
This document specifies the moq-test protocol, a testing protocol for Media over QUIC (MOQ) implementations. moq-test utilizes the Track Namespace as parameters to the publisher, enabling flexible and customizable testing scenarios. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM |
| |
|
Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the “harvest now and decrypt later” threat posed by cryptanalytically relevant quantum computers (CRQC). For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in the IKEv2 as an additional key exchange mechanism. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ] |
| | CBOR Encoding for HTTPS-based Transport for YANG Notifications |
| |
|
This document extends [I-D.draft-ietf-netconf-https-notif-15] by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes. |
| | Architectural Considerations for Environmentally Sustainable Internet Technology |
| |
| | draft-various-eimpact-arch-considerations-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Michael Welzl, Emile Stephan, Eve Schooler, Sebastien Rumley, Ali Rezaki, Jukka Manner, Carlos Pignataro, Marisol Amador, Jan Lindblad, Suresh Krishnan, Ari Keranen, Hesham ElBakoury, Luis Contreras, Alexander Clemm, Jari Arkko |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses protocol and network architecture aspects that may have an impact on the sustainability of network technology. The focus is on providing guidelines that can be helpful for protocol designers and network architects, where such guidelines can be given. |
| | DKIM2 Procedures for bounce processing |
| |
|
This memo provides a description of the procedures for bounce processing that should be performed by any mail system that implements DKIM2, as part of the overall DKIM2 protcol definition. |
| | Synchronizing caches of DNS resolvers |
| |
|
Network of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. |
| | 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. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-opsarea-rfc5706bis-03.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Individual Submissions (none) |
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define New Protocols or Protocol Extensions regarding aspects of operations and management that they should consider and include in their documents. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement to include an "Operational Considerations" section in new IETF Standard Track RFCs. |
| | Instance Information for SDF |
| |
|
This document discusses types of Instance Information to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf) and will ultimately define Representation Formats for them as well as ways to use SDF Models to describe them. // The present revision –03 is intended as input for IETF 123. |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class, sdfNonAffordance, that enables comprehensive modeling of Things and improves semantic clarity. |
| | Operational Recommendations for DS Automation |
| |
|
Enabling support for automatic acceptance of DS parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parent operator, often a registry or registrar, to make a number of technical decisions. This document describes recommendations for new deployments of such DS automation. |
| | Congestion Control Based on SRv6 Path |
| |
|
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. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-04.txt |
| | Date: |
07/07/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. |
| | Requirements of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver timely network status updates directly from the network device with a change to the device expected to react to it. FaNTEL supports fast failure and congestion notifications, enabling rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, enhancing service reliability and performance. |
| | Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability. |
| | Using ECN when Proxying UDP in HTTP |
| |
|
This document describes how to proxy the ECN bits when proxying UDP in HTTP. |
| | RESTful Provisioning Protocol (RPP) |
| |
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. |
| | Domain Name Specification for DKIM2 |
| |
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. |
| | The Use Cases for Optimizing Transport Layer Protocols in LEO and MEO Satellite Networks |
| |
|
This document introduces the use cases for the performance of existing transport protocols in LEO and MEO satellite networks. The use cases identify and demonstrate the current challenges faced by transport layer protocols in these environments. |
| | An Intent Translation Framework for IoT Networks |
| |
|
The evolution of 6G networks and the expansion of Internet of Things (IoT) environments introduce new challenges in managing diverse networked resources. Intent-based management frameworks enable operators to express desired network outcomes using high-level intents, often articulated in natural language. However, converting these expressions into machine-executable policy configurations remains an open challenge. This document defines an intent translation framework designed to bridge the gap between user-issued intents and structured policy representations for 6G enabled IoT systems. The framework accepts natural language intent as input and produces a policy document in a structured format, such as YAML, that aligns with the intent model defined in 3GPP in [TS-28.312]. The framework consists of modular components responsible for processing input, aligning user intent with domain knowledge, evaluating semantic confidence, and generating standardized output. This modularity supports transparency, interoperability, and automated policy enforcement in next-generation network infrastructures. |
| | Source Prefix Advertisement for Inter-domain SAVNET |
| |
|
This document proposes to use Source Prefix Advertisement (SPA) messages for advertising hidden source prefixes and discovering the hidden paths of source prefixes. The accuracy of existing inter- domain SAV mechanisms like EFP-uRPF can be improved by SPA. |
| | Signaling Solution for HP-WAN |
| |
|
This document proposes a technical solution for the host-network collaboration signaling to enhance the congestion control in High- Performance Wide Area Networks (HP-WAN). It also describes the RSVP extensions as an instantiation of this signaling solution. |
| | An Integrated Security Service System for 5G Networks using an I2NSF Framework |
| |
|
This document presents an integrated framework for automated security management in 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system leverages Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are then translated into enforceable network and application policies. Network-level policies are delivered to 5G core components via the Network Exposure Function (NEF), while application-level policies are enforced directly at user equipment through distributed IBN Controllers. This architecture supports adaptive, context-aware, and distributed policy enforcement, enabling real-time response to dynamic edge conditions and user mobility scenarios such as handovers. By integrating closed-loop monitoring and analytics, the system ensures consistent and autonomous security across heterogeneous 5G environments. |
| | 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. |
| | Applicability of Service & Infrastructure Maps (SIMAP) to Transport Networks |
| |
|
This document explores the applicability of the Service & Infrastructure Maps (SIMAP) concepts to transport networks and it examines the YANG data models defined by the IETF to support the requirements and use cases for SIMAP applicability to transport networks. |
| | Considerations of AI-powered Autonomic Service Agent Communication |
| |
|
ANIMA defined Autonomic Service Agent to build intelligent management functions into network devices, and could interact with each other through a standard protocol (aka GRASP).With the rapid advancement of Large Language Model (LLM)-driven AI technologies, there is now a potential opportunity to enhance the ASA to be AI-powered, thereby elevating the intelligence of device-built-in management functions to a whole new level.This document analyzes the impact of the AI-powered ASA, mostly from the perspective of the ASA communication protocol. |
| | The Impact of AI Agent to Network Infrastructure |
| |
|
This document disucss and analyses the impact of AI Agent on network infrastructure aiming to facilitate the discussion and standardization about AI Agent communication within IETF. |
| | Basic Requirements for IPv6-only Provider Edge Routers |
| |
|
This document specifies the basic requirements for multi-domain IPv6-only Provider Edge (PE) routers. The requirements cover several key aspects: support for fundamental IPv6 protocols, such as, MP-BGP and ICMPv6, implementation of 4map6 based MP-BGP extensions, stateless encapsulation and translation functions using IPv6 mapping prefixes as well as support for SRv6 and NAT64 functionalities. By defining these requirements, this document aims to facilitate the development, deployment and interoperability of such PE routers, thereby promoting the smooth establishment and operation of multi- domain IPv6-only Networks. |
| | Post-Quantum Enhancements to EAP-TLS and EAP-TTLS |
| |
|
This document proposes enhancements to the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS) and EAP Tunneled TLS (EAP-TTLS) to incorporate post-quantum cryptographic mechanisms. It also addresses challenges related to large certificate sizes and long certificate chains, as identified in RFC9191, and provides recommendations for integrating PQC algorithms into EAP-TLS and EAP- TTLS deployments. |
| | IPsec problems when used in NTN network |
| |
|
This document describes the problems in the use of IPsec in satellite Internet and NTN network scenarios. |
| | SRv6 TE Endpoint Protection |
| |
|
SRv6 TE achieves precise traffic engineering by strictly defining the traffic path (e.g., specifying particular nodes or links) through a predefined SID list. To address the failure of TI-LFA FRR protection in SRv6 TE Policy scenarios due to strict node constraints, this paper proposes an SRv6 designated Midpoint protection. |
| | Transport Network Level Use Cases |
| |
|
With the continuous growth of business volume, the transmission rate and number of network elements have increased sharply, and energy consumption of transport network has increased accordingly. Rising power costs due to significant energy consumption in transport networks necessitate energy-saving measures. To address this, adjusting energy consumption strategies according to different service requirements to optimize efficiency, ensuring quality while eliminating waste. Furthermore, regular network optimization and energy efficiency assessments enhance equipment performance and extend lifespan, thereby controlling long-term operational costs. Integrating energy-saving concepts into transport network operations proactively supports sustainable development. This document presents two transport network level GREEN use cases, aiming to facilitate discussions within the GREEN Working Group on the potential benefits, challenges, and requirements. The use cases follow a structured template that is proposed for all GREEN use cases, ensuring consistency and comparability across different scenarios. |
| | Extending Trusted Path Routed: Issues in Runtime Trust Assessment and Monitoring |
| |
| | draft-rats-runtime-tpr-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Ioannis Krontiris, Thanassis Giannetsos, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines architectural challenges and open issues in extending the Trusted Path Routing model to include runtime trust assessment and monitoring. It is intended as input to ongoing discussions within the RATS and Trusted Path Routing work. |
| | A Protocol-agnostic Multiple Agents Interaction Model for Autonomous Network |
| |
|
In the push toward Level 4 Autonomous Networks, CSPs must to adopt new processes and organizational changes, along with function-centric building blocks for higher autonomy. As intelligent agents evolve, network autonomy increasingly relies on deploying these agents, enabling self-management, self-healing, and adaptation with minimal human intervention. These agents facilitate the transition toward fully autonomous network operations across multiple layers, including services and resources. However, achieving Level 4 autonomy, where networks independently handle tasks across various domains, presents significant challenges, notably secure, efficient, and accurate multi-agent interactions. This document introduces a protocol- agnostic data model that enables multiple intelligent agents to communicate effectively using the model, ensuring end-to-end task execution and closed-loop operations in autonomous networks. |
| | KEM-based Authentication for EDHOC |
| |
| | draft-pocero-authkem-edhoc-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Lidia Fraile, Christos Koulamas, Apostolos Fournaris, Evangelos Haleplidis |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies extensions to the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) mechanisms for both key exchange and authentication. It defines a Key Encapsulation Mechanism (KEM)-based authentication method to enable signature-free post-quantum authentication when PQC KEMs, such as NIST-standardized ML-KEM, are used. |
| | External Relationship model for SIMAP |
| |
|
abstract |
| | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios |
| |
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. |
| | Applying BGP-LS Traffic Engineering Extensions to BGP-LS-SPF |
| |
|
This documents propose to introduce the BGP Link-State (BGP-LS) extensions for Traffic Engineering(TE) to the BGP-LS-SPF SAFI. |
| | Decentralized RPKI Repository Architecture |
| |
|
The Resource Public Key Infrastructure (RPKI) plays a crucial role in securing inter-domain routing. However, the current RPKI Repository system suffers from fundamental limitations in reliability, scalability, and security. In particular, single-point failures at repository publication points (PPs), the growing number of bidirectional connections with relying parties (RPs), and the lack of mechanisms to mitigate misbehavior by certification authorities (CAs) pose significant risks to the integrity, authority, and resilience of the global RPKI ecosystem. This document proposes the Decentralized RPKI Repository (dRR), a novel repository architecture that decouples RPKI object signing from data distribution. dRR introduces a distributed federation of certificate servers (CSs) and a layer of Monitors to achieve robust, scalable, and auditable RPKI data management. The architecture maintains full compatibility with the existing RPKI trust model rooted in the five RIR trust anchors, enabling incremental deployment without disrupting current relying parties (RPs) validation semantics. By doing so, dRR addresses longstanding repository challenges and enhances the overall trustworthiness and efficiency of RPKI-based routing security. |
| | Integration of Remote Attestation with Key Negotiation and Distribution |
| |
|
This draft proposes a lightweight security enhancement scheme based on remote attestation—key negotiation integrated into remote attestation. Organically integrating the main steps of end-to-end key negotiation into the remote attestation process may provide more security and flexibility. |
| | Problem Statement and Gap Analysis for Agent-enabled Mobile Core Network |
| |
|
This document provides the problem statement and gap analysis of agent-enabled mobile core network. |
| | AI Agent Use Cases and Requirements in 6G Network |
| |
|
This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. |
| | Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network |
| |
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in MPLS networks. By extending existing OAM mechanisms such as ping, traceroute, the proposed solution enables comprehensive NRP support in MPLS networks. |
| | BGP Specific Route Refresh |
| |
|
In certain scenarios, a BGP router may not require its peer to update all routes within an address family, but rather only the specific routes it needs. For example, in an EVPN network, a router might only require updates for all MAC/IP Advertisement Routes or all IP Prefix Advertisement Routes, or even just a subset of IP Prefix routes. This document presents a method for requesting the update of specific routes from a peer, thereby minimizing the impact of additional BGP updates. |
| | DNS data representation for use in RESTful Provisioning Protocol (RPP) |
| |
|
This document proposes a unified, extensible JSON representation for DNS resource records for use in the RESTful Provisioning Protocol (RPP). The aim is to create a single, consistent structure for provisioning all DNS-related data - including delegation, DNSSEC, and other record types - that directly mirrors the DNS data model and being mappable to existing EPP model of requests and responses same time. This approach simplifies the adoption of both current and future DNS features by aligning the provisioning format with the target system, thereby streamlining the management of domain names and related objects within RPP. |
| | Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option |
| |
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE option, where the field Partial IV specifies the sequence number value used by the message sender. In the interest of encrypting as much information as reasonably possible, this document defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option. Therefore, it updates RFC 8613. Combined with the update of OSCORE identifiers, the encryption of Partial IV values helps counteracting on-path adversaries that attempt to correlate the sequence numbers observed in different network paths, in order to track OSCORE endpoints that perform a network path migration. The defined encryption method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). |
| | Generative AI for Intent-Based Networking |
| |
| | draft-cgfabk-nmrg-ibn-generative-ai-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Pietro Cassara', alberto_gotta, Giuseppe Fioccola, Aldo Artigiani, Riccardo Burrai, Emiljan Kolaj |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. |
| | A YANG Data Model for SIMAP |
| |
| | draft-havel-nmop-simap-yang-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Olga Havel, Nigel Davis, Benoit Claise, Oscar de Dios, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for Service & Infrastructure Maps (SIMAP). It extends the RFC8345 YANG modules to support all SIMAP requirements. This document will only focus on modelling proposal for each of the requirements not supported by RFC8345. Any related terminology, concepts, use cases and requirements are defined outside of this draft and this draft will only refer to them, analyze how to model and propose the implementation solutions. |
| | In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) allows two peers to compute a shared secret session key. Once the session key is available, the two peers can use the EDHOC_Exporter interface, e.g., to derive keying material for an application protocol. This document defines an in-band approach that can be used by the two peers to agree about the lengths of the outputs produced with the EDHOC_Exporter interface. The defined approach relies on an EDHOC External Authorization Data (EAD) item that can be exchanged in the first two EDHOC messages of an EDHOC session. |
| | Multipath TCP with external keys |
| |
|
This document proposes an extension to Multipath TCP that allows application layer protocols such as TLS or SSH to provide keys to authenticate the creation of new subflows. |
| | Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP |
| |
|
This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. |
| | Reclassifying NAT64 (RFC6146) to Internet Standard |
| |
|
This document reclassifies Stateful NAT64 ([RFC6146]) to Internet Standard. |
| | CNI Telco-Cloud Benchmarking Considerations |
| |
|
This document investigates benchmarking methodologies for Kubernetes Container Network Interfaces (CNIs) in Edge-to-Cloud environments. It defines performance, scalability, and observability metrics relevant to CNIs, and aligns with the goals of the IETF Benchmarking Methodology Working Group (BMWG). The document surveys current practices, introduces a repeatable benchmarking frameworks (e.g., CODEF), and proposes a path toward standardized, vendor-neutral benchmarking procedures for evaluating CNIs in microservice-oriented, distributed infrastructures. |
| | Multipath TCP with longer DSS mappings |
| |
|
This document proposes an extension to improve Multipath TCP based on operational experience by allowing Multipath TCP to use DSS mappings that are longer than 64 KBytes. |
| | Reclassifying RFC6052 to Internet Standard |
| |
|
This document reclassifies IPv6 Addressing of IPv4/IPv6 Translators ([RFC6052]) to Internet Standard. |
| | Reclassifying EAM (RFC7757) to Internet Standard |
| |
|
This document reclassifies Explicit Address Mappings for Stateless IP/ICMP Translation ([RFC7757]) to Internet Standard. |
| | IETF Network Slice Service Benchmarking |
| |
|
Network slicing aims to provide assurance of specific network performance objectives for network services which require both connectivity and specific performance commitment. Such network services are considered as network slice services. This document provides a benchmarking methodology for network slicing, focusing on evaluating the key functionalities of network slicing mechanisms and the performance of network slice services. The network slicing functionalities includes the data plane, control plane and management plane mechanisms for realizing network slice service, and the performance of network slice service includes the service level agreement (SLA) commitments (bandwidth, delay, and jitter), path constraints and resource guarantee. The tests aim to demonstrate how network slicing can support competing services in a shared network, ensuring that critical network services in one network slice remain unaffected by congestion or unexpected behavior of other traffic in the same network. |
| | Knowledge Graph for Network Traffic Monitoring and Analysis |
| |
|
This document extends the knowledge graph framework to the field of traffic monitoring, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. |
| | Reclassifying SIIT (RFC7915) to Internet Standard |
| |
|
This document reclassifies IP/ICMP Translation Algorithm ([RFC7915]) to Internet Standard. |
| | ECN and DSCP support for HTTPS's Connect-UDP |
| |
|
HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. QUIC and Real-time transport protocol (RTP) are examples of transport protocols that use UDP and support Explicit Congestion Notification (ECN) and provide the necessary feedback. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP. |
| | The IPv6 Multicast Routing Headers (MRH) |
| |
|
This document describes the IPv6 extensions to support an experiment in which new IPv6 Routing headers that support stateless replication are implemented and deployed for IPv6 Segment Routing Networks. Collectively, these headers are called Multicast Routing Header (MRH). One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment. |
| | Energy-aware Routing Using Flex-Algo in Segment Routing |
| |
|
This document proposes enhancements to the Segment Routing (SR) Flexible Algorithm (Flex-Algo) framework by integrating power consumption metrics into routing decisions. It introduces metrics encompassing both node-level and link-level energy consumption attributes and proposes dynamic energy-aware path computation. By incorporating these metrics alongside traditional routing parameters, the enhanced Flex-Algo framework can enable networks to optimize routing paths for energy efficiency, and then leverage on advances router capabilities to further reduce operational costs as well as supporting sustainability objectives. |
| | Workload Identifier Scope Hint for TLS ClientHello |
| |
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier scopes in the ClientHello message. Each scope consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier scopes serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). |
| | Secondary Certificate Authentication of HTTP Clients |
| |
|
This document defines a mechanism for HTTP/2 and HTTP/3 clients to provide additional certificate-based credentials after the TLS handshake has completed, using TLS Exported Authenticators. Unlike traditional client authentication during the TLS handshake, this mechanism allows clients to present multiple certificates over the lifetime of a session. |
| | DNS Protocol Modifications for Authoritative Delegation Point DNS Records |
| |
|
This document proposes modifications to the Domain Name System (DNS) protocol to support a range of authoritative resource record types at delegation points. Currently, the DNS only allows DS (Delegation Signer) records at a delegation point as authoritative data. This draft extends that model by enabling the inclusion of a range of RRtypes at delegation points. The proposed modifications preserve compatibility with existing DNS resolution behavior while providing a clear framework for identifying and processing these records as authoritative data at delegation points. |
| | AI Agent protocols for 6G systems |
| |
| | draft-stephan-ai-agent-6g-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Emile Stephan, Roland Schott, Diego Lopez, Xiaodong Duan, Lionel Morand |
| | Working Group: |
Individual Submissions (none) |
|
Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols. |
| | Extensions to TLS FATT Process |
| |
|
This document proposes a new "Formal Analysis Considerations" section where the authors provide a threat model, informal security goals, and a protocol diagram. This document applies only to non-trivial extensions of TLS, which require formal analysis. |
| | MSD Consideration in Path Computation Element Communication Protocol (PCEP) |
| |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. An SR Policy can be instantiated SR-MPLS and SRv6 data planes. Maximum SID Depth (MSD) specifies the maximum number of SIDs that a Path Computation Client (PCC) is capable of imposing on a packet. The number of SIDs in an SR-TE path computed by the PCE on behalf of a PCC is dictated by the MSD value at the PCC. This draft specifies some MSD considerations PCE needs to take into account when computing the number of SIDs in an SR-TE path. |
| | SRv6 BGP Unreachable Prefix Announcement (UPA) |
| |
|
Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This mechanism, referred to as Unreachable Prefix Announcement (UPA), has been specified for IGPs. This document specifies an and equivalent BGP mechanism for multi-AS networks where BGP is used to carry summary routes. |
| | Static Context Header Compression Over 5G |
| |
| | draft-mokdad-schc-into-5g-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Amina MOKDAD, Laurent Toutain, Xavier Lagrange, Alexander Pelov |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a possible integration of Static Context Header Compression [RFC8724] into 5G networks. |
| | YANG Data Model for Virtual Network Interfaces Management |
| |
|
This document defines a YANG data model for the management of VNIs (Virtual Network Interfaces), including vNIC and CNI, depending on the different ways of virtualization. It exposes the real-time VNI resources to network controller and service orchestrator in order to supervise the cloud resource states for dynamic adjustment of service function placement and load-balancing of service instances to ensure the SLO (Service Level Objective). |
| | Consideration for IP-Based Satellite Routing Protocol |
| |
|
This document examines the advantages, challenges, and current research on IP-based satellite routing, and provides some considerations. |
| | Supply Chain Use Cases to Design Secure Computing Systems for SCITT Extension |
| |
|
This document includes a collection of representative Computational Supply Chain Use Cases. These use cases aim to identify computational supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. |
| | Hierarchical Topology for Language Model Coordination |
| |
|
This document defines a YANG data model and reference architecture for a hierarchical topology of language models (LMs), where tiny, small, and large LMs cooperate to perform distributed inference, summarization, and decision-making. The model supports secure inter-node messaging, request escalation, token-based authorization, and decentralized validation using pluggable trust models. This architecture is designed for deployments where computational capabilities vary across nodes, such as edge-to-cloud environments or multi-tier AI systems. The goal is to provide a standards-based mechanism for orchestrating scalable, secure LM interactions across heterogeneous systems. |
| | BGP Extensions for Service Routing of Mobile Core Networks |
| |
|
This document describes a new route propagation and service discovery mechanism by proposing BGP extensions for mobile core network service routing. The proposed solution introduces a Service Route Address Family, hierarchical Network Identifier allocation, and path-aware routing mechanisms that enable scalable inter-domain service discovery while preserving compatibility with current 3GPP standards. These extensions provide the foundation for efficient service propagation, route aggregation, and loop-free routing in large-scale distributed mobile core deployments. |
| | Multimodal Management Requirements for AI Agent Protocols |
| |
|
This document specifies the Multimodal requirements for Agent-to- Agent Protocol, which enables autonomous agents to establish multi- channel communication sessions, negotiate heterogeneous data capabilities (e.g., text, file, real-time audio/video streams, sensor streams), and exchange synchronized multimodal content with adaptive QoS policies. |
| | A YANG Data Model for Reporting Utilization Scores in ISAC |
| |
|
This document defines a basic YANG data model to report sensing measurements utilization score (US) in Integrated Sensing and Communication (ISAC) systems. The score quantifies the resource impact of different sensing measurements, including compute, memory, storage, energy, and latency. The model supports per-measurement telemetry reporting. |
| | AAuth - Agentic Authorization OAuth 2.1 Extension |
| |
|
This document defines the Agent Authorization Grant, an OAuth 2.1 extension allowing a class of Internet applications - called AI Agents - to obtain access tokens in order to invoke web-based APIs on behalf of their users. In the use cases envisaged here, users interact with AI Agents through communication channels - the Public Switched Telephone Network (PSTN) or texting - which do not permit traditional OAuth grant flows. Instead, AI agents collect Personally Identifying Information (PII) through natural language conversation, and then use that collected information to obtain an access token with appropriately constrained scopes. A primary considering is ensuring that the Large Language Model (LLM) powering the AI Agent cannot, through hallucination, result in impersonation attacks. |
| | Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines how Datagram Transport Layer Security (DTLS) 1.3 is used to establish keys for securing SCTP using the DTLS Chunk mechanism. It specifies how a DTLS handshake is used to establish the initial security context for an SCTP association and describes procedures for key updates and post-handshake authentication. The goal is to enable authenticated, and confidential communication over SCTP using the DTLS Chunk, leveraging standardized DTLS features for key management and rekeying. |
| | The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, and easy to implement. |
| | LSP Ping/Traceroute for Prefix SID in Multi-Algorithm/Multi-Topology Networks |
| |
|
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] works well in single topology, single algorithm deployments where each Prefix SID is only associated with a single IP prefix. In multi-topology networks, or networks deploying multiple algorithms for the same IP Prefix, MPLS echo request needs to carry additional information in the Target FEC Stack sub-TLVs to properly validate IGP Prefix SID. This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix Segment ID FEC sub-TLVs to also include algorithm identification while maintaining backwards compatibility. This document also introduces new Target FEC Stack sub-TLVs for Prefix SID validation in multi-topology networks. |
| | Multipath Traffic Engineering Capabilities |
| |
|
Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of the tunnel. This memo shows how this information can be distributed in the IGP via Link State Routing TE Capabilities. |
| | Matching-first Route Origin Validation |
| |
|
Route Origin Validation (ROV) using the Resource Public Key Infrastructure (RPKI) enables BGP routers to identify illegitimate routes that violate Route Origin Authorizations (ROAs). However, widespread deployment of RPKI requires validation systems to process high volumes of route announcements against increasingly large ROA datasets, where ROV adoption faces significant barriers due to concerns about its processing efficiency. This document identifies a performance issue inherent in current ROV procedure, which could be exacerbated as the expanding coverage of ROAs. |
| | RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels |
| |
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. |
| | Delay-Tolerant Networking Architecture |
| |
| | draft-cerf-dtn-4838bis-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Vinton Cerf, Scott Burleigh, Robert Durst, Kevin Fall, Keith Scott, Jordan Torgerson, Howard Weiss |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an architecture for delay-tolerant and disruption-tolerant networks. It is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a overlay protocol that interconnects multiple internets. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IETF DTN working group and has been widely reviewed by that group. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Multipath Traffic Engineered Directed Acyclic Graph (MPTED) Tunnels |
| |
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using Path Computation Element Communication Protocol (PCEP) in a stateful PCE model. |
| | Task-oriented Coordination Requirements for AI Agent Protocols |
| |
|
AI agent communication requires intelligent task level coordination to manage dynamic workloads across large-scale, heterogeneous networking environments. This draft proposes general requirements for an agent protocol to enable autonomous task coordination at scale, including dynamic task discovery, negotiation, and context- aware scheduling with real-time adaptability. |
| | P2P Chat with MoQ |
| |
|
This protocol is designed for small groups of users sending relatively small messages. It is optimized for the assumption that a node will come online and collect all messages at least once every 15 days and that some nodes that act as mirrors will be online most of the time but may come and go over long periods of time. |
| | Detecting the Presence of a Malicious Hub in MIMI Protocol |
| |
|
This document defines a Merkle-tree-based approach that can act as an audit-layer detection mechanism to identify a malicious hub, responsible for interoperable group communication between various messaging platforms. The proposed approach is based on the MIMI protocol, which uses a central hub for timestamping and broadcasting messages to clients operating on different platforms. Even though all MLS ciphertexts are end-to-end encrypted, they are routed through the hub, making it a lucrative attack surface for message reordering attacks. To detect such attacks, the proposed approach suggests creating Merkle proofs of messages and timestamps on the client-side, which can subsequently be broadcast to other clients for verification with local Merkle proofs. The broadcast messages are encrypted too and are sent probabilistically to avoid being dropped by the hub. If any of the proofs do not match, an alert is broadcast to the room, indicating a malicious hub. The approach has minimal communication overhead for practical purposes. |
| | Post-quantum Hybrid Key Exchange with NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of NTRU in the Internet Key Exchange Protocol Version 2 (IKEv2), following the framework defined in RFC 9370. RFC 9370 introduces a mechanism that enables multiple key encapsulation mechanisms (KEMs) to be used within IKEv2, allowing up to seven additional key exchange methods to be negotiated alongside the initial key exchange. This document defines how NTRU can be used as an additional key exchange method to improve the post-quantum security of IKEv2 by broadening algorithmic diversity. [EDNOTE: IANA KE code points for NTRU will be needed to be assigned. ] |
| | Voice Conversation (vCon) Consent Attachment |
| |
| | draft-vcon-consent-00.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Thomas McCarthy-Howe, Steve Lasker |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a consent attachment type for Voice Conversations (vCon), establishing standardized mechanisms for recording, verifying, and managing consent information within conversation containers. The consent attachment addresses privacy compliance challenges through structured metadata including consenting parties, temporal validity periods, and cryptographic proof mechanisms. The specification defines the mandatory and optional fields for consent attachments, including expiration timestamps, party references, dialog segments, and consent arrays. It supports granular consent management through purpose-based permissions and integrates with the AI Preferences vocabulary for automated processing systems. The attachment type incorporates SCITT (Supply Chain Integrity, Transparency, and Trust) for cryptographic transparency and provides integration patterns for consent ledger services. Key features include automated consent detection during conversation processing, auditable consent records with cryptographic proofs, support for consent revocation through superseding statements, and integration with existing privacy regulations. The consent attachment enables organizations to maintain compliance while providing sufficient structure for automated processing and verification of consent throughout the vCon lifecycle. |
| | Privacy Pass Authentication for Media over QUIC (MoQ) |
| |
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. |
| | A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions |
| |
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. |
| | Mapping Open Cybersecurity Schema Framework Events to Media over QUIC Transport |
| |
|
This document defines a mapping specification for representing Open Cybersecurity Schema Framework (OCSF) events, categories, and profiles using Media over QUIC Transport (MOQT) tracks. The mapping leverages MOQT's hierarchical data model and publish/subscribe architecture to enable real-time, in-network cached, scalable distribution of cybersecurity event data across networks while maintaining OCSF's structured taxonomy and semantic relationships. |
| | YANG Data Model for SRv6 Next Hop of Route |
| |
|
This document defines a YANG data module for configuring and managing SRv6 next hop information for Routing, which augments the YANG data model for Routing Management (RFC8349). |
| | Fiat-Shamir Transformation |
| |
|
This document describes how to construct a non-interactive proof via the Fiat–Shamir transformation, using a generic procedure that compiles an interactive proof into a non-interactive one by relying on a stateful hash object that provides a duplex sponge interface. The duplex sponge interface requires two methods: absorb and squeeze, which respectively read and write elements of a specified base type. The absorb operation incrementally updates the sponge's internal hash state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with various hash functions based on permutation or compression functions. This specification also defines codecs to securely map elements from the prover into the duplex sponge domain, and from the duplex sponge domain into verifier messages. |
| | SD-JWT-based Verifiable Credentials (SD-JWT VC) |
| |
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. |
| | Token Status List (TSL) |
| |
|
This specification defines a mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. |
| | 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. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
| | draft-ietf-opsawg-yang-provenance-01.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integritu of datasets and/or data streams. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Rishabh Parekh, Dan Voyer, Clarence Filsfils, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. A SR P2MP Policy consists of Candidate Paths (CP) which define the topology of P2MP tree instances in each Candidate Path. A P2MP tree instance is instantiated by a set of Replication segments. This document specifies the architecture, signaling, and procedures for SR P2MP Policies within Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) dataplane. It defines the P2MP Policy construct, the roles of the root and leaf nodes, Candidate Paths and and how P2MP trees using Replication Segments are instantiated and maintained. Additionally, it describes the required extensions for a controller to support P2MP path computation and provisioning. |
| | Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. |
| | Multipath Support for IGMP/MLD Proxy |
| |
|
This document describes multipath support for Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as channel/session IDs and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used to provide various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM deployments. |
| | qlog: Structured Logging for Network Protocols |
| |
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | QUIC event definitions for qlog |
| |
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | HTTP/3 qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. |
| | Multipath Extension for QUIC |
| |
| | draft-ietf-quic-multipath-15.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. |
| | Extended Key Update for QUIC |
| |
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. |
| | (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS |
| |
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| | Reference Interaction Models for Remote Attestation Procedures |
| |
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| | Concise Reference Integrity Manifest |
| |
| | draft-ietf-rats-corim-08.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. |
| | Remote Posture Assessment for Systems,Containers,and Applications at Scale |
| |
|
This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. |
| | PKIX Evidence for Remote Attestation of Hardware Security Modules |
| |
| | draft-ietf-rats-pkix-key-attestation-01.txt |
| | Date: |
07/07/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. |
| | Common Ancestor Objective Function and Parent Set DAG Metric Container Extension |
| |
| | draft-ietf-roll-nsa-extension-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thubert |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for SD-WAN Customer Premises Equipment (CPEs) to use GENEVE encapsulation (RFC8926) to transport IPsec-encrypted packets across a Cloud Backbone without requiring decryption at Cloud Gateways (GWs). In this approach, SD-WAN CPEs encapsulate IPsec-encrypted payloads within GENEVE headers and forward them to their nearest Cloud GWs. These Cloud GWs then steer the encrypted traffic through the Cloud Backbone while preserving its confidentiality, ensuring seamless transport to the destination Cloud GWs. The egress Cloud GWs subsequently deliver the original IPsec- encrypted payloads to the receiving CPEs. This mechanism enables the Cloud Backbone to interconnect multiple SD-WAN segments efficiently, eliminating the need for Cloud GWs to decrypt and re-encrypt payloads, thus enhancing the performance. |
| | Secure Asset Transfer (SAT) Use Cases |
| |
| | draft-ietf-satp-usecases-05.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Venkatraman Ramakrishna, Thomas Hardjono, Peter Liu |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. |
| | 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. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-05.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| | Standard Communication with Network Elements (SCONE) Protocol |
| |
| | draft-ietf-scone-protocol-02.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Standard Communication with Network Elements (scone) |
|
This document describes a protocol where on-path network elements can give endpoints their perspective on what the maximum achievable throughput might be for QUIC flows. |
| | Structured vacation notices |
| |
|
This document describes a machine-readable format for conveying unavailibility information in email messages. This includes "vacation notices" of persons but also different forms of unavailibility for emails sent by programs. Structured vacation notices are supposed to be used in conjunction with conventional, human-readable vacation notices in most cases. They are based on the forthcoming "structured email" specification defined in [I-D.ietf-sml-structured-email-03] and related drafts. |
| | 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). |
| | SPICE SD-CWT |
| |
| | draft-ietf-spice-sd-cwt-04.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. |
| | Use Cases for SPICE |
| |
|
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| | YANG Data Model for SRv6 Base and Static |
| |
| | draft-ietf-spring-srv6-yang-05.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Syed Raza, Jaganbabu Rajamanickam, Satoru Matsushima, Pingping Yu, Xufeng Liu |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | SRv6 and MPLS interworking |
| |
|
This document describes SRv6 and MPLS/SR-MPLS interworking procedures. Interworking problem is generalized into various interworking scenarios. These scenarios are stitched either by transport interworking or service interworking. New SRv6 behaviors are defined for the purpose. These new behaviors and MPLS labels stitch end to end path across different data plane. |
| | OCSP Usage for Secure Telephone Identity Certificates |
| |
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. |
| | Out-of-Band STIR for Service Providers |
| |
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. |
| | Connected Identity for STIR |
| |
|
The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework, however, provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog- terminating events by intermediaries or third parties. |
| | Encrypted Payloads in SUIT Manifests |
| |
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. |
| | Secure Reporting of Update Status |
| |
| | draft-ietf-suit-report-13.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| | Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domain |
| |
|
A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format for use in deployments with multiple trust domains. |
| | Cryptographic Algorithms for Internet of Things (IoT) Devices |
| |
| | draft-ietf-suit-mti-22.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019). |
| | IETF Network Slice Application in 3GPP 5G End-to-End Network Slice |
| |
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. |
| | IETF Network Slice Controller and its Associated Data Models |
| |
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. |
| | Return Routability Check for DTLS 1.2 and DTLS 1.3 |
| |
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. |
| | A well-known URI for publishing service parameters |
| |
| | draft-ietf-tls-wkech-08.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Stephen Farrell, Rich Salz, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows traffic keys to be refreshed during a session, it does not introduce new forward-secret key material. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby re-establishing forward secrecy beyond the initial handshake. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement. |
| | Operational Guidance on Coexistence with Classic ECN during L4S Deployment |
| |
|
This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. |
| | Configuring UDP Sockets for ECN for Common Platforms |
| |
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. |
| | 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. |
| | The WebTransport Protocol Framework |
| |
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. |
| | WebTransport over HTTP/3 |
| |
|
WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. |
| | WebTransport over HTTP/2 |
| |
| | draft-ietf-webtrans-http2-12.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie |
| | Working Group: |
WebTransport (webtrans) |
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. |
| | Workload Identity in a Multi System Environment (WIMSE) Architecture |
| |
| | draft-ietf-wimse-arch-05.txt |
| | Date: |
07/07/2025 |
| | Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |
| | Workload Identity Practices |
| |
|
This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture [I-D.ietf-wimse-arch] and other protocols, such as [I-D.ietf-wimse-s2s-protocol]. |