| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | Constrained Application Protocol (CoAP): Corrections and Clarifications |
| |
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) |
| |
| | draft-ietf-jose-hpke-encrypt-10.txt |
| | Date: |
20/06/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 additional 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. |
| | CAA Security Tag for Cryptographically-Constrained Domain Validation |
| |
| | draft-ietf-lamps-caa-security-02.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which attempt to tamper with communications between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man- in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically-constrained domain validation procedures. |
| | User Discovery Requirements |
| |
|
This document defines requirements for the user discovery problem within the More Instant Messaging Interoperability (MIMI) working group. User discovery is essential for interoperability, allowing message senders to locate recipients across diverse platforms using globally unique, cross-service identifiers (e.g., email addresses, phone numbers). The core challenge involves reliably mapping these identifiers to messaging service providers and determining the reachability of a recipient's identifier across multiple providers. |
| | Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing |
| |
| | draft-perkins-manet-aodvv2-06.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Charles Perkins, John Dowdell, Lotte Steenbrink, Victoria Pritchard |
| | Working Group: |
Individual Submissions (none) |
|
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. |
| | Merkle Tree Certificates |
| |
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding delay factors, which are functions of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. |
| | Identity Assertion Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through a common enterprise identity provider using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| | Data Fields for Congestion Measurement |
| |
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement data fields in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, assist in effective load balancing, and simplify network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data-Fields can be encapsulated into a variety of protocols, such as IPv6, Segment Routing Header (SRH), Network Service Header (NSH), Generic Network Virtualization Encapsulation (Geneve), etc. |
| | IPv6 Options for Congestion Measurement |
| |
|
The Congestion Measurement enables precise congestion control, assists in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document defines how Congestion Measurement Data Fields are encapsulated in IPv6. |
| | A YANG Data Model for CMIS Access and Control |
| |
|
This document provides a YANG data model to access to and control CMIS for controlling Digital Coherent Optics device equipped in a router or a switch from outside. CMIS has custom pages which enables to be defined by the module vendor for its own usage, and allows to extend the uses of the optics devices. |
| | BIMI on an Independent MUA |
| |
|
This document describes a method by which a receiving MTA may insert Brand Indicators for Message Identification (BIMI) headers into a message in such a way that a third party MUA can not only use the information in those headers but also validate that the headers were inserted by the MTA. |
| | OAuth Client Registration on First Use with SPIFFE |
| |
|
The OAuth framework is a widely deployed authorization protocol standard that enables applications to obtain limited access to user resources. OAuth clients must be registered with the OAuth authorization server, which poses significant operational challenges in dynamically scaling environments. The Secure Production Identity Framework For Everyone (SPIFFE) is a graduated Cloud Native Compute Foundation project designed to dynamically attest and verify workload identity. This draft describes how workloads with SPIFFE credentials can be used with OAuth to lessen the operational burden of client registration through a "register on first use" principle. |
| | Certificate Update in TLS 1.3 |
| |
|
This document defines a mechanism that enables TLS 1.3 endpoints to update their certificates during the lifetime of a connection using Exported Authenticators. A new extension is introduced to negotiate support for certificate update at handshake time. When negotiated, either endpoint can provide a post-handshake authenticator containing an updated certificate, delivered via a new handshake message. This mechanism allows long-lived TLS connections to remain valid across certificate rotations without requiring session termination. |
| | Hybrid signature spectrums |
| |
|
This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
| |
| | draft-ietf-spring-stamp-srpm-19.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR networks using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies, SR IGP best paths, and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. |
| |
|
| |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-15.txt |
| | Date: |
19/06/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). |
| | Bundle Transfer Protocol - Unidirectional |
| |
|
This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. |
| | Forward Error Correction for the Bundle Transfer Protocol |
| |
|
This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | NETCONF and RESTCONF Private Candidate Datastores |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | HTTP Message Signatures Directory |
| |
|
This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as new HTTP Method Context to allow for in-band key discovery. |
| | HTTP Message Signatures for automated traffic Architecture |
| |
|
This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. |
| | Web bot auth Glossary |
| |
|
Automated traffic authentication presents unique security challenges, constraints, and opportunities that impact all Internet users. This document seeks to collect terminology and examples within the space, with a specific focus on AI related technologies. |
| | Fragmentation Revisited: For What It's Worth |
| |
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. |
| | Secure Reporting of Update Status |
| |
| | draft-ietf-suit-report-12.txt |
| | Date: |
19/06/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. |
| | WIMSE Workload to Workload Authentication |
| |
| | draft-ietf-wimse-s2s-protocol-05.txt |
| | Date: |
19/06/2025 |
| | Authors: |
Brian Campbell, Joe Salowey, Arndt Schwenkschuster, Yaron Sheffer |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. |
| |
|
| |
| | A Vocabulary For Expressing AI Usage Preferences |
| |
|
This document proposes a standardized vocabulary for expressing preferences related to how digital assets are used by automated processing systems. This vocabulary allows for the creation of structured declarations about restrictions or permissions for use of digital assets by such systems. |
| | Indicating Preferences Regarding Content Usage |
| |
|
Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines how preferences can be signaled as part of the acquisition of content in HTTP. This document updates RFC 9309 to allow for the inclusion of usage preferences. |
| | EVPN Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end-to-end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-09.txt |
| | Date: |
18/06/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. |
| | 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. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using IOAM data fields. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-06.txt |
| | Date: |
18/06/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. |
| | Proxying Ethernet in HTTP |
| |
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. |
| | Flexible Hybrid PQ MLS Combiner |
| |
|
This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ confidentiality and authenticity that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e., an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. |
| | Some Key Terms for Network Fault and Problem Management |
| |
| | draft-ietf-nmop-terminology-19.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Nigel Davis, Adrian Farrel, Thomas Graf, Qin WU, Chaode Yu |
| | Working Group: |
Network Management Operations (nmop) |
|
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG models and management protocols that report, make visible, or manage network faults and problems. |
| | Indicating Non-Availability of Dynamic Updates in the DNS |
| |
|
The Start of Authority Resource Record in the Domain Name System includes various parameters related to the handling of data in DNS zones. These parameters are variously used by authority-only servers, caching resolvers and DNS clients to guide them in the way that data contained within particular zones should be used. One particular field in the SOA RR is known as MNAME, which is used to specify the "Primary Master" server for a zone. This is the server to which clients use Dynamic Update to send DNS UPDATE messages. Many zones do not support the Dynamic Update, and any such DNS UPDATE messages which are received provide no usual purpose. For such zones it may be preferable not to receive updates from clients at all. This document proposes a convention by which a zone operator can signal to clients that a particular zone does not support Dynamic Update. |
| | BGP Next-next Hop Nodes |
| |
|
BGP speakers learn their next hop addresses for NLRI in RFC-4271 in the NEXT_HOP field and in RFC-4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. |
| | Definition for Aggregated BMP Route Monitoring Message |
| |
|
This document proposes an aggregated BMP route monitoring message. It can compress multiple BMP route monitoring messages into one aggregated BMP route monitoring message to reduce the amount of reported BMP route monitoring messages and reduce network overhead. This document updates RFC 7854 by adding new BMP Messages type. |
| | A method for describing changes made to an email |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. |
| | IP in Deep Space: Key Characteristics,Use Cases and Requirements |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on the Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. |
| | New Key Share Extension for Classic McEliece Algorithms |
| |
|
RFC 8446 is modified to where another key share extension is introduced to accommodate both public keys and ciphertexts in ClientHello and ServerHello messages for post-quantum algorithms that have large public keys, including algorithms of the code-based cryptographic scheme Classic McEliece. |
| | 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. |
| | ICMPv6 Prefix Redirect Messages |
| |
|
The existing IPv6 ICMPv6 Redirect Message informs a host of a better next hop for a single destination IPv6 address. There is now a use case for informing a host of a better next hop for a prefix of IPv6 addresses that includes or covers the single destination address that triggered the ICMPv6 redirect message. This memo specifies an ICMPv6 Prefix Redirect Message for this purpose. |
| | Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 |
| |
| | draft-yusef-tls-pqt-dual-certs-00.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Rifaat Shekh-Yusef, Hannes Tschofenig, Mike Ounsworth, Yaron Sheffer, Tirumaleswar Reddy.K, Yaroslav Rosomakho |
| | Working Group: |
Individual Submissions (none) |
|
This document extends the TLS 1.3 authentication mechanism to allow the negotiation and use of two signature algorithms to enable dual- algorithm hybrid authentication, ensuring that an attacker would need to break both algorithms to compromise the session. The two signature algorithms come from two independent certificates that together produce a single Certificate and CertificateVerify message. |
| | 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. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-13.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document proposes a scalable architecture for single-issuer signed statement transparency applicable to any supply chain. It ensures flexibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-09.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "circuit-style" SR Policy (CS-SR Policy). |
| | Amplification Attacks Using the Constrained Application Protocol (CoAP) |
| |
|
Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-19.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for IETF transports that enables fast startup of CC for a wide range of connections. It reuses a set of computed CC parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the CC behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of Careful Resume impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |
| |
|
| |
| | ACME End User Client and Code Signing Certificates |
| |
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support service account authentication credentials, micro-service accounts credentials, device client, code signing, document signing certificates and keys. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-07.txt |
| | Date: |
17/06/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. |
| | Common YANG Data Types for Layer 0 Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-15.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-15.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). |
| | Use of ML-KEM in the Cryptographic Message Syntax (CMS) |
| |
| | draft-ietf-lamps-cms-kyber-10.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Julien Prat, Mike Ounsworth, Daniel Van Geest |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameters sets for the ML-KEM algorithm are specified by NIST in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML- KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure. |
| | LISP Geo-Coordinates |
| |
|
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo- Coordinate. This document updates RFC8060. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the changed data was observed. |
| | Proxy MAC-IP Advertisement in EVPNs |
| |
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. |
| | dry-run DNSSEC |
| |
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in every record of a DS RRset, referred to as dry-run DS, signal to validating resolvers that dry- run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of the dry-run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. |
| | SR Policy Group |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR Policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR Policy and SR Policy Group to provide best practice cases for operators. |
| | Reliability Framework for SRv6 Service Function Chaining |
| |
|
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. SR can be instantiated on the MPLS data plane (MPLS-SR) and the IPv6 data plane (SRv6). On the MPLS-SR data plane, a segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. On the SRv6 data plane, a segment is encoded as an IPv6 address (SRv6 SID) [RFC8986], and an ordered list of segments is encoded as an ordered list of SRv6 SIDs in the SR header (SRH) [RFC8754]. The ingress node steers packets into a specific path according to the ordered list of segments (SR Policy) as defined in [RFC9256]. Service Function Chaining (SFC) defines an ordered set of service functions and subsequent "steering" of traffic through them. The architecture of SFC is defined in [RFC7665]. This document describes the common failure scenarios and protection mechanisms of service function chains in SR networks. Then implementation recommendations for protection of service function chains are proposed. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | YANG Data Model for SR Policy Group |
| |
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. |
| | Segment Routing based Solution for Hierarchical IETF Network Slices |
| |
|
This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. |
| | ASPA-based AS_PATH Verification for BGP Export |
| |
|
This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers, check for local misconfigurations and detect ASPA registration errors, thus avoiding the advertisement of invalid routes. |
| | SRv6 Path Verification |
| |
|
This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specificed by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. And this approach also significantly reduces the processing overhead associated with hop-by- hop path verification. |
| | Verifiable Voice Protocol |
| |
|
Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technolgies such as SHAKEN, RCD, and BCID, VVP can bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses stronger, richer evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit Error Rate Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the bit error rate within the "Extra Padding" TLV of STAMP packets. |
| | The Reason for Abandoning the UPA Draft |
| |
|
[I-D.ietf-lsr-igp-ureach-prefix-announce] (UPA draft) proposes the solution to announce the prefix unreachable information within the IGP domain. It utilizes the LSInfinity concept that is introduced in [RFC2328], without analyzing the dormant and flawed design. The proposal doesn't work even in simple scenario, is based on one flawed feature, lacks the explicit withdrawn procedures. This document analyzes the above issues, suggests the IETF commuity abandon the UPA draft, replace it with other more comprehensive document [I-D.wang-lsr-prefix-unreachable-annoucement](Founder Draft), to provide the IETF community the more optimal solution. |
| | Signalling a Zone Cut to Nowhere in the DNS |
| |
|
This document defines a standard means to signal that a zone cut exists in the DNS without specifying a set of nameservers to which a child zone is delegated. This is useful in situations where it is important to make it clear to clients that a zone cut exists, but when the child zone is only provisioned in a private namespace. |
| | Extension Registry for the Extensible Provisioning Protocol |
| |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-12.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-ietf-pquip-hbs-state-00.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
Stateful Hash-Based Signature Schemes (S-HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large- scale quantum computers. Unlike conventional stateless digital signature schemes, S-HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered. |
| | Device Schema Extensions to the SCIM model |
| |
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. |
| | Hybrid key exchange in TLS 1.3 |
| |
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. |
| | Prefer use of RFC8781 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis |
| |
|
On networks providing IPv4-IPv6 translation (NAT64, RFC7915), hosts and other endpoints might need to know the IPv6 prefix used for translation (the NAT64 prefix). While RFC7050 defined a DNS64-based prefix discovery mechanism, more robust methods have since emerged. This document provides updated guidelines for NAT64 prefix discovery, deprecating the RFC7050 approach in favor of modern alternatives (e.g., RFC8781) whenever available. |
| |
|
| |
| | BGP based Multi-homing in Virtual Private LAN Service |
| |
|
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-07.txt |
| | Date: |
16/06/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-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments the notification capabilities model. The module provides transport protocol, transport encoding, and transport encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | SID as source address in SRv6 |
| |
|
In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. |
| | eXtensible Stateless Equipment Data Exchange |
| |
| | draft-guy-xfsp-02.txt |
| | Date: |
16/06/2025 |
| | Authors: |
Mark Spencer, Edward Guy, , Nick Hartley |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a binary IP-based protocol to facilitate interoperable communications between electronic equipment on a platform. The protocol is UDP-based, stateless, and multicast. Messages consist of a common header followed by a series of parameters and related attributes. The parameters are always informational, e.g., indicating airspeed is 150 kts, but parameter attributes can be set to indicate intent, e.g., this parameter contains a new user selected value such as an instruction that deploys the landing gear. Although initially designed for avionics, it can be applied to other platform domains as well. This document defines the core protocol and a method to extend it to meet any domain specific needs. |
| | Simple Local Web PKI Certificate Resource Preservation Management for Internet Browser |
| |
|
The management of Web PKI certificate resources presents a challenge when the misalignment of ownership and management rights over certificate resources of one organization creating a risk of unilateral suspension and revocation by another competing organizations. This situation undermines the stability of critical infrastructure and affects the integrity of authentication systems. To address these concerns, this document proposes a mechanism that allows Internet browsers to create a customized management view of certificate resources, enabling them to override the verification results from specific certification authorities as needed. This approach enhances security, facilitates stakeholder collaboration, and preserves the operational integrity of foundational industry systems. |
| | Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of G-PON Encapsulation Method entities in the Passive Optical Transport of the Optical Distribution Network. |
| | The Fast Software Authenticated Encryption HiAE |
| |
| | draft-pham-cfrg-hiae-01.txt |
| | Date: |
16/06/2025 |
| | Authors: |
Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the high throughput authenticated encryption algorithm HiAE designed for new wireless generation 6G and data transmission applications. |
| | Updates to OAuth 2.0 Security Best Current Practice |
| |
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. |
| | Proxy for Congestion Notification |
| |
|
This document describes the necessity and feasibility to introduce a proxy network node between the congested network node and the traffic sender. The proxy network node is used to translate the congestion notification. The congested network node sends the congestion notification to the proxy network node in a format defined in this document, and the proxy network node translates the received congestion notification to a format known by the traffic sender and resends the translated congestion notification to the traffic sender. |
| | Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages. |
| |
|
This document aims to standardize the validation of mutual TLS authentication between servers (server-to-server). It outlines recommended validation flows as well as provides practical design recommendations. Basically the EKU id-kp-clientAuth and id-kp- serverAuth get more precisely defined to represent their common understanding by issuing CAs and browsers. id-kp-clientAuth aka. "TLS WWW client authentication" SHOULD mean authentication of a natural or legal entity. id-kp-serverAuth aka. "TLS WWW server authetnication" SHOULD mean authentication of a device. When two id- kp-clientAuth certificates are used this means E2E authentication between two users. Where as two id-kp-serverAuth certificates being used means server-to-server authentication. And one user and one server certificate within one TLS connection means client-to-server (or technically also server-to-client). The term "TLS-Client" SHOULD no longer be used and mean the party sending the initial package while establishing a TLS connection. This helps to avoid design issues moving forward as currently some people thought TLS-Client auth was only ever used in "client-to-server" and never within "server-to-server" context. Which sparked the demand for this document to begin with to keep server-to-server auth with public trusted certificates working. |
| | RPKI Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| | Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations |
| |
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. |
| | 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. |
| | IANA Registry Updates for TLS and DTLS |
| |
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. |
| | Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings |
| |
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR). |
| |
|
| |
| | An Attribute for Statement of Possession of a Private Key |
| |
|
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. |
| | MPLS Network Action for Deterministic Latency |
| |
|
This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains. |
| | 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. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3. |
| | ICMP Error Handling in SRv6 based VPN Networks |
| |
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). |
| | Priority-based Flow Control SID in SRv6 |
| |
|
To address the issue of lossless transmission for cross-data center services, the PFC (Priority-based Flow Control) mechanism can be extended to wide-area networks (WANs) to solve packet loss caused by network congestion and the problem of backpressure signal transmission between WAN and RoCEv2 network in data centers. By leveraging SRv6 and slicing technologies, it is possible to effectively control the propagation range and path of PFC backpressure signals in wide-area networks, thereby avoiding issues such as deadlocks and the excessive propagation of congestion scope. PFC is a hop-by-hop mechanism. Given that most current WAN devices do not support PFC function, this document proposes defining a new type of SRv6 SID End.X.PFC to indicate the PFC-capable interface in the WAN network. |
| | Adapting Constrained Devices for Post-Quantum Cryptography |
| |
|
This document offers guidance on incorporating Post-Quantum Cryptography (PQC) into resource-constrained devices, including IoT devices and lightweight Hardware Security Modules (HSMs), which operate under tight limitations on compute power, memory, storage, and energy. It highlights the role of the Root of Trust in enabling secure operations, including seed-based key generation to reduce the need for persistent storage, efficient approaches to managing ephemeral keys, and methods for offloading cryptographic tasks in low-resource environments. Additionally, it examines how PQC affects firmware update mechanisms in such constrained systems. |
| | Secure Asset Transfer (SAT) Interoperability Architecture |
| |
| | draft-ietf-satp-architecture-07.txt |
| | Date: |
15/06/2025 |
| | Authors: |
Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. |
| |
|
| |
| | A YANG Data Model for Network Incident Management |
| |
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and probable cause analysis. |
| | Semantic Definition Format (SDF) modeling for Digital Twin |
| |
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. |
| | Terminology for Energy Efficiency Network Management |
| |
| | draft-bclp-green-terminology-02.txt |
| | Date: |
14/06/2025 |
| | Authors: |
Peter Liu, Mohamed Boucadair, Qin WU, Luis Contreras, Marisol Amador |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | IAB Processes for Management of IETF Liaison Relationships |
| |
|
This document discusses the procedures used by the IAB to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers, and the expectations of the IAB in establishing liaison relationships. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. To foster interoperability, deterministic encoding is mandated. Furthermore, the document outlines how deterministic encoding combined with enhanced CBOR tools, enable cryptographic methods like signing and hashing, to optionally use "raw" (non-wrapped) CBOR data as input. This document mainly targets CBOR tool developers. |
| | QUIC Stream Resets with Partial Delivery |
| |
|
QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. |
| | Cryptographic Algorithm Recommendations for Software Updates of Internet of Things Devices |
| |
| | draft-ietf-suit-mti-18.txt |
| | Date: |
14/06/2025 |
| | Authors: |
Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This document specifies cryptographic algorithm profiles to be used with the Software Updates for Internet of Things (suit) manifest. These profiles define mandatory-to-implement algorithms to ensure interoperability. |
| | TLS Encrypted Client Hello |
| |
| | draft-ietf-tls-esni-25.txt |
| | Date: |
14/06/2025 |
| | Authors: |
Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher Wood |
| | Working Group: |
Transport Layer Security (tls) |
|
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. 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/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). |
| |
|
| |
| | RTP Payload Format for sub-codestream latency JPEG 2000 streaming |
| |
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given image can be emitted before the entire image is available to, or encoded by, the sender. |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. |
| | TLS Extension for DANE Client Identity |
| |
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. |
| | Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs) |
| |
|
An 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, which provide advanced features such as guaranteed resources, bounded latency or jitter to meet specific customer connectivity requirements. When Segment Routing (SR) is used for building NRPs, each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. In some network scenarios, each NRP can be associated with a unique logical network topology. When a centralized network controller is used for NRP-specific constraint-based path computation, especially when an NRP spans multiple IGP areas or multiple Autonomous Systems (ASes), BGP-LS is needed to advertise the NRP topology and associated resource information to the network controller. This document describes a mechanism to distribute the information of SR based NRPs using BGP-LS with MT. |
| | Problems and Requirements of Addressing in Integrated Space-Terrestrial Network |
| |
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. |
| | Cisco's CoAP Simple Management Protocol |
| |
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. |
| | Testing async submission |
| |
|
This draft is submitted only to test the async api submission endpoint |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | Stateless MNA-based Egress Protection (SMEP) |
| |
|
The MPLS Egress Protection Framework specifies a fast reroute framework for protecting IP/MPLS services. To that end, bypass tunnels have to be signaled to the Point of Local Repair (PLR). Further, the PLR must maintain the bypass forwarding state on a per- transport-tunnel basis. This document presents the concept of Stateless MNA-based Egress Protection (SMEP). SMEP protects egress routers by providing alternative MPLS egress labels in-stack. This mechanism does not require a bypass forwarding state in PLRs. An example for the application of SMEP is given using a MPLS network action for stack management. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. |
| | Procedures for Handling Liaison Statements to and from the IETF |
| |
|
This document describes the procedures for generating and handling liaison statements between the IETF and other SDOs, so that the IETF can effectively collaborate with other organizations in the international standards community. |
| | Extensible YANG Model for Network Telemetry Messages |
| |
|
This document defines an extensible message schema in YANG to be used at the data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables a data collection to add metadata for the provenance of the operational network data. |
| | 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). |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-opsarea-rfc5706bis-02.txt |
| | Date: |
13/06/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Thomas Graf, 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 should be considered. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement for an "Operational and Management Considerations" section in Internet-Drafts, before they are progressed for publication as RFCs. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-03.txt |
| | Date: |
13/06/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. |
| | MPLS Network Action for Stack Management |
| |
|
The MPLS Network Action (MNA) framework provides a general mechanism for the encoding and processing of network actions and their data. This document introduces a network action to the MPLS Network Action (MNA) framework for stack management operations including MOVE-N-LSE and POP-N-LSE. The MOVE-N-LSE operation elevates a specified number of LSEs within the stack and the POP-N-LSE operation removes a specified number of LSEs. The stack management operations can be used to facilitate various applications. As an example, a mechanism called HBH preservation which reduces the readable label depth (RLD) requirement in nodes is presented. |
| | Signaling MNA Capabilities Using IGP |
| |
|
This document defines capabilities of nodes supporting MPLS Network Actions (MNA) and how to signal them using IS-IS and OSPF. The capabilities include the Readable Label Depth (RLD), supported network action opcodes, and the maximum sizes of differently scoped Network Action Sub-stacks (NAS), called the NAS_MLD. For IS-IS and OSPF signaling, sub-TLV encodings based on existing mechanisms to signal node- and link-specific capabilities are leveraged. |
| | Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems |
| |
|
This document specifies extensions to the Entity Attestation Token (EAT) [RFC9248] to support robust, interoperable attestation of capabilities in agentic AI systems. These extensions introduce new claims and guidance for securely asserting agent functional, reasoning, and operational capabilities, as well as their compositional structure and policy constraints. The goal is to enable trustworthy, verifiable, and privacy-respecting capability attestation for autonomous agents in dynamic, decentralized environments. |
| | Extending Certificate Enrollment Protocols for Scalable Agentic AI Identity |
| |
|
Agentic AI systems require robust, verifiable identities to operate securely. While traditional certificate enrollment protocols like SCEP and EST can be extended to include remote attestation evidence, performing a full validation for every agent's certificate request presents significant scalability and privacy challenges. This document proposes two distinct, scalable models for integrating attestation into the enrollment lifecycle. The first model leverages Zero-Knowledge Proofs (ZKP) to provide private, efficient, and continuous attestation. The second model uses a one-time, high- assurance bootstrapping process to establish a trusted host environment, which is then authorized to endorse certificate requests for the agents it runs. Both models enable high-assurance identity for AI agents while addressing the performance bottlenecks of naive per-enrollment verification. |
| | Publishing End-Site Prefix Lengths |
| |
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. |
| | SVGs in RFCs |
| |
|
This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from RFC 7996 and removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs. |
| | Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6) |
| |
|
This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages. |
| |
|
| |
| | ML-DSA for JOSE and COSE |
| |
| | draft-ietf-cose-dilithium-07.txt |
| | Date: |
12/06/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans |
| | Working Group: |
CBOR Object Signing and Encryption (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. |
| | COSE Header parameter for RFC 3161 Time-Stamp Tokens |
| |
|
This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure in COSE-based protocols. |
| | BMP YANG Module |
| |
| | draft-ietf-grow-bmp-yang-05.txt |
| | Date: |
12/06/2025 |
| | Authors: |
Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, Narasimha Prasad |
| | Working Group: |
Global Routing Operations (grow) |
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). |
| | Test Protocol for One-way IP Capacity Measurement |
| |
|
This document addresses the problem of protocol support for measuring Network Capacity metrics specified by RFC 9097. The Method of Measurement discussed there requires a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This document defines the UDP Speed Test Protocol for conducting RFC 9097 and other related measurements. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-00.txt |
| | Date: |
12/06/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. |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines common types and groupings that are meant to be used for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling status. |
| | Paired MLS - PCS in Limited Modes |
| |
|
This document describes the Paired Messaging Layer Security (MLS) extension that improves Post Compromise Security for devices that are unable to self-update using a trusted paired device. |
| | Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 |
| |
|
This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". |
| | Adaptive Routing Notification for Load-balancing |
| |
|
In this document, adaptive routing is referred to as a technology that makes dynamic traffic forwarding decisions based on changes in traffic load and network topology, devices with adaptive routing capabilities can dynamically select the outport in the forwarding table based on the congestion condition of the outport or downstream link. This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered and processed in the network. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document describes a potential protocol extension involving the addition of four new attributes to be used by servers to provide support for POSIX ACLs. The term POSIX ACLs refers to the ACL component of the Portable Operating System Interface (POSIX) 1003.1e draft 17 document for which sponsorship was withdrawn in January 1998. Although the draft POSIX standard that describes these ACLs was never ratified, several POSIX-based operating systems, such as Linux, Solaris and FreeBSD include support for them. The NFS Version 4 (NFSv4) ACLs described in Network File System (NFS) Version 4 Minor Version 1 henceforth referred to as NFSv4 ACLs, use a different model and attempts to map between the ACLs of these two models have not been completely successful. In order to adequately support POSIX ACLs, this document proposes four new attributes that may optionally be used by an NFS Version 4, minor version 2 (NFSv4.2) server to support ACLs that conform to the aforementioned POSIX 1003.1e draft 17. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | Concise Selector for Endorsements and Reference Values |
| |
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. |
| | Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0 |
| |
|
The Automatic Certificate Management Environment (ACME) protocol allows server operators to obtain TLS certificates for their websites, based on a demonstration of control over the website's domain via a fully-automated challenge/response protocol. OpenID Federation 1.0 defines how to build a trust infrastructure using a trusted third-party model. It uses a trust evaluation mechanism to attest the possession of public keys, protocol specific metadata and various administrative and technical information related to a specific entity. This document defines how X.509 certificates associated with a given OpenID Federation Entity can be issued by an X.509 Certification Authority through the ACME protocol to the organizations which are part of a federation built on top of OpenID Federation 1.0. |
| | Announce Existence of Parent CDS/CSYNC Scanner |
| |
|
In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties.  This document proposes an extension to the semantics of the DSYNC resource record, as defined in [I-D.draft-ietf-dnsop-generalized-notify], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | An EAT Profile for Device Attestation |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust the device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be consumed by 3rd party attestation services external to the TVM, there is a need to standardise the representation of Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | The HPKE Elligator KEM |
| |
|
This document contains the GNUnet communicator specification. This document defines the normative wire format of communicator protocols, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNUnet communicators, guide future communicator implementations, and ensure interoperability among implementations including with the pre-existing GNUnet implementation. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| | SSH Agent Protocol |
| |
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. |
| | Proportional Rate Reduction for TCP |
| |
|
This document specifies a standards-track version of the Proportional Rate Reduction (PRR) algorithm that obsoletes the experimental version described in RFC6937. PRR regulates the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm. |
| |
|
| |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-19.txt |
| | Date: |
11/06/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for the detection of BFD packet loss. |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. |
| | Template-Driven HTTP CONNECT Proxying for TCP |
| |
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| | Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 |
| |
|
In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues. |
| | 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. |
| | remoteStorage |
| |
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. |
| | MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) |
| |
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. |
| | STI Certificate Transparency |
| |
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR eco-system, focusing on verifiable control over telephone number or service provider code resources. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Model-driven Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the data manifest, composed of two YANG data models (the platform manifest and the non-normative data collection manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The data manifest must be streamed and stored along with the data, up to the collection and analytics systems in order to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. |
| | Guidelines for Characterizing "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. |
| | The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 |
| |
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| | An sdfType for Links |
| |
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). |
| | Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
| |
|
Distributed computing is a computing pattern that service providers can follow and use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, compute intensive and delay sensitive services can be improved by utilizing computing resources hosted in various computing facilities. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response time. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to better meet the customer's expectations. |
| | 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 sublayer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. |
| | A YANG Network Data Model of Network Inventory Software Extensions |
| |
|
The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for non-physical NEs (e.g., controllers, virtual routers, virtual firewalls) and software components (e.g., platform operating system (OS), software-patch). |
| | Transport Layer Protocol Requirement for LEO satellite |
| |
|
In recent years, high-bandwidth LEO (Low Earth Orbit) satellite networks, such as Starlink and OneWeb, have seen tremendous development and are gradually becoming an important part of the global Internet. However, due to the unique characteristics of satellite networks, using TCP for data transmission faces challenges in multiple aspects, such as high latency caused by long-distance propagation and high error rates due to signal attenuation. This proposal summarizes the basic requirements that need to be considered for designing transport layer protocols tailored to LEO satellites. |
| | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document is a necessary revision of RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing compliant implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications to its implementers and users. |
| | Forwarding Commitment BGP Testbed and Deployment Experience |
| |
|
Forwarding Commitment BGP (FC-BGP) enables the establishment of a secure inter-domain routing system by providing security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. In an effort to enhance the validation of FC-BGP, a prototype implementation of the FC-BGP was developed and an evaluation was conducted on the FITI high-performance IPv6 backbone network. This document reports on the prototype implementation and the results of the evaluation. |
| | Technical Considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT) |
| |
|
This document analyses the gaps of the existing transport layer technologies and provides technical considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT). |
| | LEO transport problem statement |
| |
|
LSN, Starlink and OneWeb, can provide global Internet connectivity with latency comparable to terrestrial networks, but their fast movement and frequent handovers result in highly dynamic connectivity changes. The fast movement of LSN will introduce frequent handover and varying link delays every few minutes. As the path over LSN varies, TCP cannot tell whether changes in packet loss or RTT are due to path changes or network congestion, thus it might not be able to make proper adjustment. This greatly impact the performance of TCP. |
| | Segment Routing based Network Resource Partition (NRP) for Enhanced VPN |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. 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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". Segments can represent topological or service based instructions. Segments can further be associated with a set of network resources used for executing the instruction. Such segments are called resource-aware segments. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. |
| |
|
| |
| | EVPN Fast Reroute |
| |
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) or Link Layer Discovery Protocol (LLDP) in Software-Defined Networking (SDN). In a traditional Software-Defined Networking, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems |
| |
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. |
| | Fast Congestion Notification Packet (CNP) in RoCEv2 Networks |
| |
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. |
| | STAMP Extensions for DetNet |
| |
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time of High Performance Wide Area Networks (HP-WAN). It focuses on key congestion control functions to facilitate host-to-network collaboration and perform rate negotiation, such as QoS policy, admission control, and traffic scheduling. |
| | Privacy Preference Declaration for Home Networks |
| |
|
This document proposes a framework that empowers users to define and enforce privacy policies within their home networks through a Privacy Preference Declaration (PPD) protocol. As connected devices proliferate, this approach enhances user control by enabling user- defined privacy settings for different data types, automatic policy discovery by new devices, and accountability measures such as notifications, network restrictions, or perhaps reporting non- compliance with users' defined preferences to designated authorities. The framework aims to cultivate a privacy-conscious home network environment through clear, enforceable privacy governance. |
| | Privacy Preference Declaration Taxonomy |
| |
|
This document defines a standardized taxonomy for describing data handling practices of Internet-connected devices within home networks. It complements the Privacy Preference Declaration (PPD) Protocol by providing the necessary vocabulary and semantic structure to represent and reason about data types, purposes, actions, sources, and destinations. This taxonomy supports both machine reasoning and human interpretation and can be implemented using ontological frameworks such as OWL-DL. |
| | A Profile for Route Path Authorizations (RPAs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). |
| | BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects |
| |
|
The Route Path Authorizations (RPA) is an RPKI object that attests to the complete routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. |
| | Benchmarking Methodology for Computing-aware Traffic Steering |
| |
|
Computing-aware traffic steering(CATS) is a traffic engineering approach based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. |
| | Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. |
| | BIER Payload Label |
| |
|
The BIER Encapsulation RFC8296 specifies that the "Proto" field in the BIER header is set to 1 if an MPLS label stack follows the BIER header and the top of the stack label is a downstream-assigned label, and is set to 2 if the top of stack label is an upstream-assigned label, which is looked up in the context-specific label forwarding table that can be derived from the BIER header. The terms upstream/downstream-assignment are inappropriate to describe the required forwarding for new MPLS label semantics such as SRGB and DCB labels as defined in RFC8402 and RFC9573 respectively. This can result in potentially inconsistent implementation choices causing potential interoperability issues. This document rectifies this situation by changing the IANA BIER Next Protocol Identifier semantic for MPLS code points from their label semantic to the required LFIB in the forwarding plane, hence covering those new type of labels without changing behavior for existing upstream/downstream-assigned labels. |
| | The SSLKEYLOGFILE Format for TLS |
| |
|
A format that supports logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data. |
| |
|
| |
| | Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| | Integration of Speech Codec Enhancement Methods into the Opus Codec |
| |
|
This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| | Subscription to Notifications in a Distributed Architecture |
| |
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. |
| | Fast HIP Host Mobility |
| |
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. |
| | Transient Hiding of Hop-by-Hop Options |
| |
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides useful and secure semantics for RTR Protocol in particular as a single connection could carry multiple requests over streams, enabling much better efficiency and performance for both peers. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | Unified Network and Cloud Orchestration Framework |
| |
|
This draft introduces the Unified Network and Cloud Orchestration Framework (UNCO), which is designed to enable real-time and joint orchestration of network and computing resources in 5G and future- generation networks. UNCO framework addresses inefficiencies in current resource scheduling mechanisms, resolves objective conflicts across domains, and provides unified policy and security management. It is applicable in emerging scenarios such as ultra-reliable low- latency communications (URLLC), mobile edge computing (MEC), and network slicing, where service quality and operational efficiency are paramount. |
| | Transition to Full BGPsec Deployment: Transitive-BGPsec is Incompatible with BGPsec |
| |
|
This document elaborates on the reasons why it is unfeasible to reconstruct the native-BGPsec as a transitive approach, such that a BGP update with a correctly signed BGPsec_PATH attribute can traverse legacy areas and afterwards it can still be properly processed by subsequent native-BGPsec speakers. |
| | Registration Protocol for Performance and Diagnostic Metrics |
| |
|
This document specifies a registration protocol for use with Performance and Diagnostic Metrics version 2 (PDMv2). This registration process enables endpoints to communicate supported policies and capabilities in advance of measurement sessions, simplifying setup and enhancing security. The protocol defines a set of commands, responses, and message formats, and proposes integration with the Diameter Base Protocol (RFC6733) as the transport and authentication mechanism. |
| | 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. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request neighbor router(s) to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document extends Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. |
| | BIER Fast Reroute (BIER-FRR) |
| |
| | draft-ietf-bier-frr-09.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes BIER Fast Reroute (BIER-FRR) as a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. It enhances the resiliency of BIER by quickly rerouting BIER traffic in the event of a link or node failure. This ensures that multicast traffic continues to reach its intended destinations, thereby minimizing packet loss and service disruption. BIER-FRR is designed to integrate seamlessly with existing BIER operations without requiring per-flow state or additional signaling. The document suggests additional structures for BIER to hold information for backup forwarding entries and to enable them in case of detected failures. BIER-FRR can implement different protection levels, e.g., link protection or node protection, and different protection strategies. Tunnel-based BIER-FRR and LFA-based BIER-FRR are introduced as protection strategies and their implementation with the proposed extensions. A comparison highlights the differences between both approaches. |
| | Finding Tracking Tags |
| |
| | draft-ietf-dult-finding-01.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Christine Fossaceca, Eric Rescorla |
| | Working Group: |
Detecting Unwanted Location Trackers (dult) |
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. This document defines the protocol by which devices report tags they have seen and by which owners look up their location. |
| | BGP Dissemination of Flow Specification Rules for Tunneled Traffic |
| |
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. |
| | Advertising Unreachable Links in OSPF |
| |
|
In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe). |
| | Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane |
| |
|
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions, called segments. SR can be instantiated over the MPLS data plane. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to- end paths in Segment Routing networks. This document defines procedures (i.e. six new Target forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include Path Segment Identifiers. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS OAM capabilities. |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document primarily presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). This document additionally presents a third YANG module, to define a grouping for URIs. |
| | The FNV Non-Cryptographic Hash Algorithm |
| |
| | draft-eastlake-fnv-35.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| | Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that has been widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-12.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Gyan Mishra, xuewei wang, Geng Zhang |
| | Working Group: |
Individual Submissions (none) |
|
The Alternate Marking Method is a passive performance measurement method based on marking consecutive batches of packets, which can be used to measure packet loss, latency, and jitter of live traffic. This method requires a packet marking method so that packet flows can be distinguished and identified. A mechanism to carry suitable packet marking in the Hop-by-Hop Header and the Destination Options Header of an IPv6 packet is described in RFC 9343 and is also applicable to Segment Routing for IPv6 (SRv6). This document describes an alternative experimental approach that uses a new TLV in the Segment Routing Header (SRH) of an SRv6 packet. This approach has been implemented and has potential scaling and simplification benefits over the technique described in RFC 9343. The experiment is to determine whether those benefits are significant and attractive to the community: if they are, the work may be brought back for IETF consideration. 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. |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | NRP ID in SRv6 segment |
| |
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. |
| | IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
| |
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| | Encapsulation of BFD for SRv6 Policy |
| |
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | IGP Color-Aware Routing |
| |
| | draft-lin-lsr-igp-car-03.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| | YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
| |
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| | Distribute Service Metric by BGP |
| |
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| | SRv6 Resource Programming with NRP flavor |
| |
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| | MNA for Metadata in SR-MPLS Service Programming |
| |
|
This document defines MPLS Network Action(MNA) encoding to carry metadata in SR service programming with SR-MPLS data plane. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-09.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| |
|
| |
| | DRIP Entity Tags in the Domain Name System |
| |
|
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. |
| | IGP Unreachable Prefix Announcement |
| |
|
Summarization is often used in multi-area or 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 document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. |
| | Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks |
| |
| | draft-ietf-mpls-stamp-pw-01.txt |
| | Date: |
05/06/2025 |
| | Authors: |
Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without adding an IP/UDP header for PWs and LSPs. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. |
| | Advertisement of Candidate Path Validity Control Parameters using BGP-LS |
| |
|
This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc. |
| | PCEP extension to support Candidate Paths validity |
| |
|
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy. |
| | EVPN Group Policy |
| |
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. |
| | Deadline Aware Streams in QUIC Multipath |
| |
|
This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (QUIC-MULTIPATH) as well as QUIC itself. This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and ideally by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages the path identifiers introduced by the Multipath Extension for QUIC to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard endpoints using the Multipath Extension for QUIC. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths. Additionally, this proposal also maintains compatibility with QUIC itself, in order to deliver its benefits - albeit with limited effectiveness - even in scenarios where only a single path can or should be used. |
| | Evidence Package Format Specification |
| |
|
Taking evidence is a key part of any software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. |
| | The DIMG (Dual-Image) File Format Specification |
| |
|
This document specifies the DIMG (Dual-Image) file format, which encapsulates two discrete image blocks within a single file container. The format addresses common inefficiencies in handling front/back documentation scenarios by eliminating redundant file management operations and simplifying data exchange workflows. Security considerations are discussed in Section 7. |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines pure post-quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes for use in the SSH Transport Layer Protocol. |
| | Early IANA Registry Creation |
| |
|
This memo describes the requirements for publishing a registry on the IANA website before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when a Working Group needs to coordinate allocations among multiple documents or with an organization outside the IETF. |
| | Registration Data Access Protocol (RDAP) Extension for Geofeed Data |
| |
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension |
| |
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". |
| | Optimizing BFD Authentication |
| |
|
This document describes an experimental optimization to BFD Authentication. It provides procedure where only important BFD state transitions require strong authentication and permits the majority of BFD Control Packets to use a less computationally intensive authentication mechanism. This enables BFD to scale better when there is a desire to use strong authentication. |
| | 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. |
| | JSContact: Optional Unique Identifiers |
| |
|
This document redefines the mandatory "uid" property of a Card object to become optional. This is both for using JSContact in other protocols than CardDAV and JMAP for Contacts, as well as to align the semantics of the vCard UID property with JSContact. This is a breaking change, this document introduces version "2.0" to replace the current JSContact version "1.0". |
| | A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths |
| |
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-13.txt |
| | Date: |
04/06/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 works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. This document defines the use of the HPKE with COSE. |
| | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| | draft-ietf-dhc-rfc8415bis-12.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). |
| | DNSSEC Cryptographic Algorithm Recommendation Update Process |
| |
|
The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC8624 to an IANA registry. This is done both to allow the list of requirements to be more easily updated, and to allow the list to be more easily referenced. Future extensions to this registry can be made under new, incremental update RFCs. This document also incorporates the revised IANA DNSSEC considerations from RFC9157. The document does not change the status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC8624; that is the work of future documents. |
| | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) |
| |
| | draft-ietf-emu-eap-edhoc-04.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, Francisco Lopez |
| | Working Group: |
EAP Method Update (emu) |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. |
| | The eap.arpa domain and EAP provisioning |
| |
|
This document defines the eap.arpa domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers which use the Network Access Identifier (NAI) format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140. |
| | Resumable Uploads for HTTP |
| |
|
Data transfer using the Hypertext Transfer Protocol (HTTP) is often interrupted by canceled requests or dropped connections. If the intended recipient can indicate how much of the data was received prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. |
| | Comparison of CoAP Security Protocols |
| |
|
This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. |
| | Key Transparency Protocol |
| |
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. |
| | Validity of SR Policy Candidate Path |
| |
|
This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy. |
| | Certificate Status Information Mechanism Description Updates to RFC 5280 |
| |
|
The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960]. |
| | Technical guidelines of Web server certification path validation for Interent browser |
| |
|
In Web PKI, certificate path construction and validation are crucial security review processes. At present, there are many Internet browser manufacturers around the world. With the change of security practices and the development of technology, the certificate validation process in Internet browser industry is relatively messy, including various private implementations of manufacturers. It is a typical patching improvement method, and the implementation of process functions is relatively arbitrary. This document provides a technical guide for certification path validation of web server certificates during Internet SSL/TLS protocol communication for Web PKI, including the basic path verification process, as well as reference procedures, guidance and suggestions for input, initialization, and basic certificate processing in the verification process. This document is applicable to the development and application of Internet browsers, as well as other similar digital certificate authentication systems requiring SSL/TLS security protocol secure communication. |
| | Using TLS Client Authentication with DNS Handles |
| |
|
This is a discussion document prepared for the DANCE Working Group presenting possible convergence between the DNS Handles authentication approach based on OAUTH being used in the ATmosphere and the DANCE approach. User experience and architectural requirements for using TLS Client Authentication in a DNS Handles based environment are discussed. |
| | Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE) |
| |
|
This document defines a protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within a delay-tolerant network (DTN). Security associations are used to amortize the costs of asymmetric-keyed security operations and allow for efficient and high-throughput BPv7 security within a public key infrastructure. |
| | PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| | draft-ietf-pce-bier-te-02.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang |
| | Working Group: |
Path Computation Element (pce) |
|
Tree Engineering for Bit Index Explicit Replication (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE). |
| | Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search |
| |
|
The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and ASNs, which are provided by RIRs via their Whois services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. |
| | Static Context Header Compression and Fragmentation over networks prone to disruptions |
| |
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. |
| |
|
| |
| | BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
| |
| | draft-ietf-anima-brski-prm-23.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). |
| | BGP Link-State extensions for BIER |
| |
| | draft-ietf-bier-bgp-ls-bier-ext-20.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | Deprecate usage of ECC-GOST within DNSSEC |
| |
|
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") within DNSSEC. RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933 by deprecating the use of ECC-GOST. |
| | Deprecating the use of SHA-1 in DNSSEC signature algorithms |
| |
|
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms. |
| | Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| | API Keys and Privacy |
| |
|
Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. |
| | IETF Community Moderation |
| |
|
The IETF will treat people with kindness and grace, but not endless patience. This document describes the creation of a moderator team for all the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention for using the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. This approach offers the advantage of easy deployment without affecting ongoing operations. As such, the method can be applied to a domain name that is still in full use. Note to the RFC Editor This document contains several "Notes to the RFC Editor", including this section. These should be reviewed and resolved prior to publication. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification with efficient fragmentation and reassembly procedures. |
| | IPv6 Extended Fragment Header for IPv4 |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. |
| | COSE Receipts with CCF |
| |
|
This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced via Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees. |
| | 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 near real-time network status updates. FaNTEL enables fast failure and congestion notifications, supporting rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, improving service reliability and performance. |
| | CATALOG Authorization Transparency And Log Overlay for Graph-based DNS |
| |
|
This document proposes an extension to the Certification Authority Authorization (CAA) DNS Resource Record (RR) that enables the mandatory or optional binding of Certificate Transparency (CT) Log URIs directly within DNS. By embedding CT-Log endpoints in CAA RR, Certification Authorities (CAs) gain a standardized, discoverable mechanism for retrieving preferred and permitted CT-Log endpoint information, thereby enhancing the security and auditability of X.509 TLS certificate issuance. The extension defines the syntax and semantics for a new CAA property tag, *"issuect"*, and introduces a parameter set consisting of _"desc"_, _"critical"_, _"validfrom"_, _"validtill"_, _"cturi"_, _"logid"_, and _"pubkey"_. It outlines validation and processing rules, discusses deployment considerations, privacy implications, and interoperability with existing DNS, CA, and CT infrastructures. Additionally, the draft proposes an MTA-STS-like hardening mechanism, called *CAA-CT-STS*, for the new property to further strengthen the PKI ecosystem. Finally, it introduces the recursive acronym CATALOG (CATALOG Authorization Transparency And Log Overlay for Graph-based DNS) as a mnemonic for the overall extension framework. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-ietf-nvo3-rfc7348bis-00.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-29.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| |
|
| |
| | iCalendar Format Extensions for JSCalendar |
| |
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-06.txt |
| | Date: |
02/06/2025 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support |
| |
|
This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4- over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in an intermediate node rather than the client. |
| | Quality of Outcome |
| |
|
This document introduces the Quality of Outcome (QoO) framework, a novel approach to network quality assessment designed to align with the needs of application developers, users, and operators. By leveraging the Quality Attenuation metric, QoO provides a unified method for defining and evaluating application-specific network requirements while ensuring actionable insights for network optimization and simple quality scores for end-users. |
| | OSPF-GT (Generalized Transport) |
| |
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. |
| | Updates to Anycast Property advertisement for OSPFv2 |
| |
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | OpenPGP Web Key Directory |
| |
|
This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. |
| | PCEP Extensions for sid verification for SR-MPLS |
| |
|
This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Sub-Stacks |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirement for the development of the RESTful Provisioning Protocol (RPP). |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-08.txt |
| | Date: |
02/06/2025 |
| | Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| | Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. |
| | TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key |
| |
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). |
| |
|
| |
| | Requirements for Scaling Deterministic Networks |
| |
|
Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, a great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. |
| | Guidance to Avoid Use of BGP Extended Communities at Internet Exchange Route Servers |
| |
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. This document updates RFC 7948. |
| | Hybrid Public Key Encryption |
| |
| | draft-ietf-hpke-hpke-00.txt |
| | Date: |
01/06/2025 |
| | Authors: |
Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, Christopher Wood |
| | Working Group: |
HPKE Publication, Kept Efficient (hpke) |
|
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE |
| |
|
Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attack by a quantum computer. |
| | PEM file format for ECH |
| |
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. |
| | Resource Allocation Model for Hybrid Switching Networks |
| |
|
The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. |
| | Simple namespace-like proposal for JSON using a separator,for the RPP |
| |
|
This document proposes a lightweight convention for namespaces in the JSON payloads of RPP: a registry of namespaces plus the convention to write JSON names as namespace_shortname. It is not intended to be published as a RFC, just to stir discussion. |
| | Update to Automatic Bandwidth Adjustment procedure of Stateful PCE |
| |
|
Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. |