| |
|
| |
| | 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. three 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. |
| | 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. |
| | SW103K PROTOCOL |
| |
|
The SW103k protocol addresses challenges in networks with limited bandwidth, latency constraints, and data integrity concerns. It provides compression and decompression to optimize bandwidth utilization in environments such as IoT, satellite, and mobile communications. The protocol operates at the data link layer with a custom frame format including SW103K and HAVI headers. Key features include: - Batch processing of 103 packets with compression - Merkle tree- based integrity verification (merklesw103k root hash) - QoS mechanisms with 8-bit priority field - Security features including AES-256-GCM encryption - Physical layer synchronization with +-1us accuracy Implementations include Linux kernel modules, FPGA encoders, and userspace daemons. The protocol supports interoperability with industrial standards like PROFINET and EtherCAT through custom mappings. |
| | A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks |
| |
|
This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to provide servers information pertaining to the operation of an IEEE 802.11 wireless network. The document has been developed by the Wireless Broadband Alliance's Access Network Metrics project team. This project was formed to addresses the adoption of RADIUS used to support Wi-Fi authentication in environments that are increasingly complex; with multiple possible overlapping networks, operating using different Wi-Fi technology generations, utilizing varied spectrum allocations, and where the AAA provider wants to ensure their users are getting a great Wi-Fi experience. In such environments, the Wi-Fi industry can benefit from a consistent framework that provides visibility of Wi-Fi network metrics, increasing confidence in Wi-Fi to support carrier use-cases, and consequently driving adoption. The use of a well defined syntax for the Connect-Info attribute that simultaneously supports existing Wi-Fi implementations while also addressing new requirements may have wider applicability by the broader Wi-Fi community. This document is an independent submission. It is not an IETF standard and does not have IETF consensus. |
| | 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. |
| | Challenges in Transporting Sensing Data with Media Over QUIC |
| |
|
This document proposes leveraging Media Over QUIC (MOQ) to address the challenges of transmitting large-scale, real-time sensing data in 6G networks. By building on QUIC's low-latency and multiplexing capabilities, MOQ offers a flexible and efficient transport mechanism tailored to the dynamic and high-throughput requirements of 6G environments. The approach focuses on enabling protocol adaptability across diverse application scenarios such as autonomous driving, smart cities, and industrial IoT, while ensuring efficient data fragmentation, secure and anonymous transmission, and end-to-end QoS awareness. Through information-aware endpoints and optimized data delivery mechanisms, this solution supports scalable, reliable, and intelligent sensing data distribution in next-generation wireless networks. |
| | Enhancing Local-Use Domain Name Resolution within Link-Local Scope |
| |
|
Link-local networks such as home Internet of Things (IoT) and industrial Internet of Things are becoming increasingly prosperous, with a large number of small devices deployed in the link-local networks. These devices discover each other through ".local." domain names of DNS-based zero-configuration network protocol. However, the lack of specialized security operations to supervise link-local DNS resolution leads to some security risks. This memo addresses the potential risks associated with the leakage of link-local DNS traffic to external networks, the lack of identity authentication on ".local." domain requests, and the lack of rate-limiting on ".local." domain responses, which poses the leakage of link-local device information and the risk of DDoS attacks. Furthermore, the document proposes a set of best practices and technical solutions to mitigate these risks and ensure that ".local." domain name resolution remains confined within the local network segment. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | Selective Disclosure for JWTs (SD-JWT) |
| |
|
This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. |
| | Procedures for Communication between Stateful Path Computation Elements |
| |
| | draft-ietf-pce-state-sync-12.txt |
| | Date: |
29/05/2025 |
| | Authors: |
Haomian Zheng, Stephane Litkowski, Siva Sivabalan, Cheng Li |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. In some use cases, inter-PCE stateful communication can bring additional resiliency in the design, for instance, when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use cases and also the procedures to prevent computational loops. |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths and Interfaces |
| |
| | draft-ietf-teas-yang-te-38.txt |
| | Date: |
29/05/2025 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. |
| | 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 the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. |
| |
|
| |
| | 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, and code signing certificates and keys. |
| | Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks |
| |
|
Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. |
| | DTNMA Application Resource Identifier (ARI) |
| |
| | draft-ietf-dtn-ari-05.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Edward Birrane, Emery Annis, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. |
| | DTNMA Asynchronous Management Protocol (AMP) |
| |
| | draft-ietf-dtn-amp-02.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Edward Birrane, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport binding for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing remote management of resource constrained devices possibly over challenged networks. |
| | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. |
| | Certificate Management over CMS (CMC) |
| |
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFC 5273 and RFC 6402. |
| | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFC 5274 and RFC 6402. |
| | 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. |
| | Augmented-by Addition into the IETF-YANG-Library |
| |
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| | MSYNC |
| |
| | draft-bichot-msync-18.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Sophie Bale, Remy Brebion, Guillaume Bichot |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter |
| |
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter during path computation. |
| | The '_for-sale' Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention for using the reserved 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. |
| | A SAVI Solution for WLAN |
| |
|
This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. |
| | Multiple Algorithm Rules in DNSSEC |
| |
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
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 making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). |
| | Naming the Protocol specified RFC 8029 |
| |
|
RFC 8029 specifies the key MPLS Operation, Administration, and Maintenance protocol, sometimes referred to MPLS Label Switched Path (LSP) Ping, or MPLS LSP Ping. Howerver, the actual name of the protocol have never been explicitly specified or documented. This document corrects that omission. This document updates RFC 8029. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit Error Detection and 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 detection of bit errors and the measurement of the bit error rate within the "Extra Padding" TLV of STAMP packets. |
| | KerPass EPHEMSEC One-Time Password Algorithm |
| |
|
This document specifies EPHEMSEC, an algorithm for generating one- time passwords (OTPs) and one-time keys (OTKs). Unlike traditional OTP algorithms that rely solely on static shared secrets, EPHEMSEC uses public key cryptography, which simplifies secure deployment on authentication servers. EPHEMSEC also supports binding the generated OTP/OTK to contextual data. When this context is obtained and injected by a trusted agent, the resulting codes can be made resistant to phishing and man-in-the-middle attacks. Finally, EPHEMSEC includes a built-in time synchronization mechanism that embeds a synchronization hint into the generated output. This allows both parties to deterministically derive the same OTP/OTK value without requiring trial-and-error validation, enabling compatibility with protocols such as Password Authenticated Key Exchange (PAKE) and TLS with Pre-Shared Key (TLS-PSK) that require exact secret agreement. |
| | Protocol extension and mechanism for fused service function chain |
| |
|
This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. |
| | Architecture and application scenario for fused service function chain |
| |
|
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. |
| | Protocol extension and mechanism for fused service function chain |
| |
|
This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. |
| | Architecture and application scenario for fused service function chain |
| |
|
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. |
| | The OAuth 2.1 Authorization Framework |
| |
| | draft-ietf-oauth-v2-1-13.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Dick Hardt, Aaron Parecki, Torsten Lodderstedt |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. |
| | SD-JWT-based Verifiable Credentials (SD-JWT VC) |
| |
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. |
| | Standard Communication with Network Elements (SCONE) Protocol |
| |
| | draft-ietf-scone-protocol-00.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Standard Communication with Network Elements (scone) |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. |
| | A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest |
| |
| | draft-ietf-suit-manifest-34.txt |
| | Date: |
28/05/2025 |
| | Authors: |
Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Oyvind Ronningstad |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. |
| | A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
| |
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. |
| | TEEP Usecase for Confidential Computing in Network |
| |
|
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC (Multi-access Computing) and other scenarios to use confidential computing in network. |
| | Large Record Sizes for TLS and DTLS with Reduced Overhead |
| |
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead. |
| |
|
| |
| | Unicode Character Repertoire Subsets |
| |
|
This document discusses subsets of the Unicode character repertoire for use in protocols and data formats, and specifies three subsets recommended for use in IETF specifications. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-12.txt |
| | Date: |
27/05/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 one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | DTNMA Application Management Model (AMM) and Data Models |
| |
| | draft-ietf-dtn-amm-04.txt |
| | Date: |
27/05/2025 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-12.txt |
| | Date: |
27/05/2025 |
| | Authors: |
Prodosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | MUD-Based RATS Resources Discovery |
| |
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. |
| | 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. |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document 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). |
| | 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. |
| | CBOR Serialization and Determinism |
| |
|
This document updates and clarifies CBOR Serialization and Deterministic Encoding as defined in [RFC8949]. It also provides background explanations that were not included in the original specification. |
| | EchoPulse: Adaptive Symbolic KEM Framework for Low-Resource Cryptographic Systems |
| |
|
This document introduces EchoPulse, a Key Encapsulation Mechanism (KEM) designed for high efficiency and minimal resource usage, offering adaptive symbolic behavior and built-in resistance to replay and side-channel attacks. EchoPulse aims to serve as a viable lightweight PQC candidate. |
| | 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. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-10.txt |
| | Date: |
27/05/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. |
| | The PrivateToken HTTP Authentication Scheme Extensions Parameter |
| |
|
This document specifies new parameters for the "PrivateToken" HTTP authentication scheme. This purpose of these parameters is to negotiate and carry extensions for Privacy Pass protocols that support public metadata. |
| | Privacy Pass Issuance Protocols with Public Metadata |
| |
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
| | (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS |
| |
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| | Reverse Change of Authorization (CoA) in RADIUS/TLS |
| |
|
This document defines a "reverse Change of Authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. |
| | RIFT Key/Value TIE Structure and Processing |
| |
|
The RIFT (Routing in Fat Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. |
| | SRv6 Path Egress Protection |
| |
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. |
| | 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 RFC 6937. PRR provides logic to regulate 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. |
| |
|
| |
| | An Update to YANG Module Names Registration |
| |
|
This document amends the IANA guidance on the uniqueness of YANG module and submodule names. The document updates RFC 6020 to clarify how modules and their revisions are handled by IANA. |
| | Prefix Unreachable Announcement |
| |
|
This document describes a mechanism that can trigger the switchover of the services which rely on the reachability of the peer endpoints, for example the BGP or the tunnel services. It is mainly used in the scenarios that the summary prefixes are advertised at the border routers whereas the services endpoints are located in different IGP areas or levels, whose reachabilities are covered by the summary prefixes. It introduces a new signaling mechanism using a negative prefix announcement called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the overlay services that the communication endpoint is unreachabe to force the overlay service headend switchover immediately. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-09.txt |
| | Date: |
26/05/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-08.txt |
| | Date: |
26/05/2025 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | EVPN Mpls Ping Extension |
| |
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. |
| | Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network |
| |
|
This draft outlines the pluggable module attributes within a host device. It includes representations of optical pluggable module capabilities, configuration, states, and telemetry data. These attributes draws from existing IETF standards and incorporates input from other industry forums and standards, such as ITU-T, OpenConfig, OIF and ONF TAPI, to ensure uniform structuring and consistent naming conventions. Note that the IETF terminology shall be given precedence wherever possible. In case there is a duplication of an attribute, this draft may describe how the attribute is named in the related document. Only if no attribute exists in IETF RFCs or IETF WG drafts, new attributes shall be introduced if they are needed. This draft provides a gap analysis with respect to existing IETF work in the following areas: * It provides an analysis of optical attributes provided by other organizations and identifying modeling gaps in current IETF drafts. * It identifies modeling needs addressing the specific aspect of pluggability of transceiver modules. The authors recognize the fact that that not all pluggable modules are coherent, not all coherent pluggable modules are DWDM capable and not all DWDM capable interfaces are implemented as pluggable modules. This analysis identifies gaps to manage the lifecycle of an optical pluggable module, from operator approval and viability assessment, to deployment, monitoring and phase-out. The lifecycle of an optical pluggable module, from operator approval and viability assessment to deployment and monitoring, is also addressed. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://italobusi.github.io/actn-wdm-pluggable-modelling/draft-rokui- ccamp-actn-wdm-pluggable-modelling.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- rokui-ccamp-actn-wdm-pluggable-modelling/. Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/. Source for this draft and an issue tracker can be found at https://github.com/italobusi/actn-wdm-pluggable-modelling. |
| | Problem Statement with Aggregate Header Limit for IPv6 |
| |
|
This document first proposes introduces the concept "Aggregate header limit for IPv6"(IPv6-AHL) based on [RFC8883] to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. |
| | Export of SRv6 Path Segment Identifier Information in IPFIX |
| |
|
This document introduces a new IPFIX Information Element to identify the Path Segment Identifier(PSID) in the SRH for SRv6 path identification purpose. |
| | Considerations for Protective DNS Server Operators |
| |
|
Recent research work has delved deeply into a new type of DNS security service, Protective DNS, through various measurement methods, and it has been deployed in multiple DNS providers and even in national ISPs. Protective DNS identifies whether the domain names requested by customers are in the threat intelligence (blocklist) it maintains. For domain names listed in the blocklist, it rewrites the resolution results to secure resources to prevent users from accessing malicious resources, such as malicious servers (IP addresses), etc. This document summarizes the conclusions of these research works and provides specific and practical considerations and suggestions for the deployment and operation of Protective DNS. By following these considerations, Protective DNS service providers can effectively enhance the practicality and security of their services. |
| | DomainKeys Originator Recipient (DKOR) |
| |
|
DKIM associates a domain name with a message stream, using cryptographic methods, to permit reliable and accurate reputation- oriented analysis of the stream. It is possible for an authorized user to conspire for additional distribution of a message, leveraging the domain name reputation for promoting spam. This is called DKIM Replay. DKOR defines a means of limiting that ability, by associating original addressing information with the message's DKIM signature, to detect distribution beyond the intended recipient. DKOR uses existing DKIM services and only requires implementation of the additional DKOR features by the signer and any receiving site wishing to participate in DKOR services. Other DKIM receivers can successfully process the same DKIM signature without knowledge of DKOR. |
| | Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests |
| |
| | draft-ietf-suit-mti-15.txt |
| | Date: |
26/05/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. |
| | Quic Logging for Convergence of Congestion Control from Retained State |
| |
|
This document specifies a logging format for a cautious method for Careful Resume when using the IETF quic transport protocol. It defines the logging format for qlog. |
| | Neighbor Discovery Considerations in IPv6 Deployments |
| |
|
The Neighbor Discovery (ND) protocol is a critical component of the IPv6 architecture. The protocol uses multicast in many messages. It also assumes a security model where all nodes on a link are trusted. Such a design might be inefficient in some scenarios (e.g., use of multicast in wireless networks) or when nodes are not trustworthy (e.g., public access networks). These security and operational issues and the associated mitigation solutions are documented in more than 20 RFCs. There is a need to track these issues and solutions in a single document. To that aim, this document summarizes the published ND issues and then describes how all these issues originate from three causes. Addressing the issues is made simpler by addressing the causes. This document also analyzes the mitigation solutions and demonstrates that isolating hosts into different subnets and links can help to address the three causes. Guidance is provided for selecting a suitable isolation method to prevent potential ND issues. |
| |
|
| |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-19.txt |
| | Date: |
25/05/2025 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence and Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-11.txt |
| | Date: |
25/05/2025 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3 and QUIC |
| |
|
This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. |
| | 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. |
| | Deprecating Insecure Practices in RADIUS |
| |
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The recent publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give recommendations for practices which increase both security and privacy. |
| | YANG Data Model for Segment Routing Policy |
| |
| | draft-ietf-spring-sr-policy-yang-05.txt |
| | Date: |
25/05/2025 |
| | Authors: |
Syed Raza, Tarik Saleh, Shunwan Zhuang, Dan Voyer, Muhammad Durrani, Satoru Matsushima, Vishnu Beeram |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. |
| |
|
| |
| | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| | draft-ietf-dhc-rfc8415bis-11.txt |
| | Date: |
23/05/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). |
| | 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. |
| | BGP UPDATE for SD-WAN Edge Discovery |
| |
|
The document describes the BGP mechanisms for SD-WAN (Software Defined Wide Area Network) edge node attribute discovery. These mechanisms include a new tunnel type and sub-TLVs for the BGP Tunnel- Encapsulation Attribute [RFC9012] and set of NLRI (network layer reachability information) for Software-Defined Wide-Area Network (SD- WAN) underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turn propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. |
| | 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. |
| | Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security |
| |
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC8784, but also protects the initial IKEv2 SA. RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made as part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
|
This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It includes protocol extensions made as part of the respecification effort for NFS Minor Version 1. It obsoletes and replaces RFC5662. |
| | 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. |
| | 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. |
| | JSON Web Token Best Current Practices |
| |
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. |
| | SCHC Context lifecycle and management |
| |
|
Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism. SCHC operation is based on a common static Context stored at the two (or more) ends of a communication. As the scope of SCHC becomes broader, the static Context needs to evolve towards a more dynamic Context. This purpose of this document is to initiate a discussion on the lifecycle of a Context. It describes the main steps in the lifecycle of a SCHC Context, and more broadly, it aims at documenting the related Requirements and Terminology for the proper use of SCHC. These goals are in line with the Working Group's objectives, as set out in the Charter: * "Produce an informational document describing how a carried protocol can use SCHC", * "Produce Standard Track documents for SCHC Rule Discovery and Parameter Negotiation", * "Produce Standard Track documents for SCHC Rule Provisioning". |
| | OAuth 2.0 step-up authorization challenge proto |
| |
|
It is not uncommon for resource servers to require additional information like details of delegation authorization, or assurance proof of the delegation of authorization mechanism used according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the data and metadata associated with the access token of the current request does not meet its authorization requirements and, further, how to meet them. This document also codifies a taxonomy to guide the client into starting a new request towards the authorization server in order to get issued, if applicable, a new set of tokens matching the requirements. |
| | Token Status List |
| |
|
This specification defines a mechanism, data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-12.txt |
| | Date: |
23/05/2025 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for efficient multi-point packet delivery in a Segment Routing (SR) domain. A SR P2MP Policy consists of Candidate Paths (CP) which define the topology of P2MP tree instances in each Candidate Path. A P2MP tree instance is instantiated by a set of Replication segments. This document specifies the architecture, signaling, and procedures for SR P2MP Policies within Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) dataplane. It defines the P2MP Policy construct, the roles of the root and leaf nodes, Candidate Paths and and how P2MP trees using Replication Segments are instantiated and maintained. Additionally, it describes the required extensions for Path Computation Element (PCE) to support P2MP path computation and provisioning. |
| | 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. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-28.txt |
| | Date: |
23/05/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.] |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-18.txt |
| | Date: |
23/05/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. |
| |
|
| |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) |
| |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | 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. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |
| | IGP Unreachable Prefix Announcement |
| |
|
In the presence of summarization, 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. |
| | 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. |
| | Supporting In Situ Operations,Administration and Maintenance Using MPLS Network Actions |
| |
| | draft-ietf-mpls-mna-ioam-02.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Rakesh Gandhi, Greg Mirsky, Tony Li, Haoyu Song, Bin Wen |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and record the operational state and telemetry information using, for example, Pre- allocated, Proof-of-Transit, Edge-To-Edge or Incremental IOAM Option, that can be used to calculate various performance metrics. RFC 9326 defined the IOAM Direct Export (IOAM-DEX) Option in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy on each node along the path. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transfer data needed for these actions. This document explores the MNA mechanisms to collect and transport the on-path operational state, and telemetry information IOAM data fields, including IOAM-DEX Option. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-ietf-mpls-mna-ps-hdr-00.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Tony Li, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data specific requirements found in "Requirements for MPLS Network Actions." This document follows the architectural framework for the MPLS Network Actions (MNA) technologies specified in "MPLS Network Actions (MNA) Framework." |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-04.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | pretty Easy privacy (pEp): Email Formats and Protocols |
| |
| | draft-pep-email-03.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Hernani Marques, Bernie Hoeneisen |
| | Working Group: |
Individual Submissions (none) |
|
The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (such as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption viable for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). |
| | YANG Data Model for MPLS LSP Ping |
| |
| | draft-nainar-mpls-lsp-ping-yang-07.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Nagendra Nainar, Madhan Sankaranarayanan, Jaganbabu Rajamanickam, Carlos Pignataro, Guangying Zheng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. |
| | pretty Easy privacy (pEp): Privacy by Default |
| |
| | draft-pep-general-03.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Volker Birk, Hernani Marques, Bernie Hoeneisen |
| | Working Group: |
Individual Submissions (none) |
|
The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer- to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like data minimization, end-to-end and interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. |
| | Intel Profile for Remote Attestation |
| |
|
This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes apticulareplication of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers. |
| | Parallel NFS (pNFS) Flexible File Layout Version 2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data protection is also added to provide integrity. Both Client-side mirroring and the Mojette algorithm are used for data protection. |
| | 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. |
| | 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. |
| | The tag-42 profile of CBOR Core |
| |
|
This document defines a strict profile of CBOR Core (CBOR/c) intended for use with the special tag 42. Like the CBOR Core it profiles, "CBOR/c-42" can also be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR/c-42 objects link to one another by hash-based identifiers, deterministic encoding is mandated to verify dereferenced links and encode new ones. This document mainly targets CBOR tool developers and those downstream users who would like to precisely configure their tools. While full support in CBOR tools would be ideal and is already possible in some highly configurable parsing libraries, ALDRs can help close the delta by sidestepping the biggest interoperability stumbling blocks; see Appendix C for details. |
| | Polynomial Commitment Schemes |
| |
|
This document describes the high-level interface of a polynomial commitment scheme (PCS), a cryptographic primitive used in constructing generic zk-SNARKs. A PCS allows a prover to commit to a polynomial, and later attest to its correct evaluation at a given point. Test vectors and reference implementations for popular instantiations are provided in Appendix A. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
| | draft-ietf-opsawg-ipfix-alt-mark-03.txt |
| | Date: |
22/05/2025 |
| | Authors: |
Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Yongqing Zhu, Mauro Cociglio |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) |
| |
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. |
| | Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions |
| |
|
This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions. This document updates RFC 6487. |
| | IPv6 CE Routers LAN DHCPv6 Prefix Delegation |
| |
|
This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes that were delegated to a IPv6 CE router. This document updates RFC 7084. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN extensions (RFC8505, RFC8928, RFC8929, RFC7400) 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 to request neighbor router(s) to redistribute the prefix in a larger routing domain regardless of the routing protocol used in the larger domain. This document extends RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the registered prefix in RPL. |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-19.txt |
| | Date: |
21/05/2025 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (slice provider) is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | 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. [RFC Editor: please remove this before publication: It is unclear if updating RFC5933 (a Historic document) is the correct thing to do or not. We did it so that it shows up in Datatracker and similar, but this may be a mistake. We are happy to change this if the RFC Editor / IESG / whoever thinks this is a bad idea.] |
| | 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. |
| | 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. |
| | DRIP Entity Tags in the Domain Name System |
| |
|
This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata. |
| | 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. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | Deterministic Route Redistribution into BGP |
| |
|
In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. To eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. Additionally, We recommend automatically lowering the LOCAL_PREF value in implementation for the redistributed backup route when appropriate. |
| | Deadline Based Deterministic Forwarding |
| |
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. |
| | Network-based mobility management in CATS network environment |
| |
|
Computing-Aware Traffic Steering (CATS) network architecture is to choose the best edge computing server by considering both the network environment and available computing/storage resources of the edge computing server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress CATS-Router by using the PMIPv6-based mobility management method in the CATS-based edge computing networking environment. |
| | Terminal-based joint selection and configuration of MEC host and DETNET-RAW network |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | Extensions to enable wireless reliability and availability in multi-access edge deployments |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | MIPv6 DETNET-RAW mobility |
| |
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| | Fully Adaptive Routing Ethernet using LSR |
| |
| | draft-xu-lsr-fare-04.txt |
| | Date: |
21/05/2025 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination over multiple equal-cost paths, based on network capacity and even congestion information along those paths. |
| | IPv4 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs for both existing Internetworking pathways and a new link model for the future. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. |
| | IPv6 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of-packets", while AJs offer essential operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Networking (DTN) link model. |
| | Fully Adaptive Routing Ethernet using BGP |
| |
| | draft-xu-idr-fare-03.txt |
| | Date: |
21/05/2025 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Tiezheng |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, often consisting of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network become increasingly critical for large-scale AI models. Therefore, adaptive routing is necessary to dynamically distribute the traffic to the same destination over multiple equal- cost paths, based on the network capacity and even congestion information along those paths. |
| | IETF Network Requirements |
| |
|
This document aims to initiate a conversation to clarify the way forward to address disagreements within the community about the requirements for the IETF meeting network, how it is delivered and whether or not the current cost and effort of providing the network is reasonable. |
| | Fully Adaptive Routing Ethernet in Scale-Up Networks |
| |
| | draft-xu-rtgwg-fare-in-sun-01.txt |
| | Date: |
21/05/2025 |
| | Authors: |
Xiaohu Xu, Zongying He, Hua Wang, Tianyou Zhou, Yongtao Yang, Yinben Xia, Peilong Wang, Yan Zhuang, Fajie Yang, Chao Li, Xiaojun Wang |
| | Working Group: |
Individual Submissions (none) |
|
The Mixture of Experts (MoE) has become a dominant paradigm in transformer-based artificial intelligence (AI) large language models (LLMs). It is widely adopted in both distributed training and distributed inference. Furthermore, the disaggregation of the prefill and decode phases is highly beneficial and is considered a best practice for distributed inference models; however, this approach depends on highly efficient Key-Value (KV) cache synchronization. To enable efficient expert parallelization and KV cache synchronization across dozens or even hundreds of Graphics Processing Units (GPUs) in MoE architectures, an ultra-high- throughput, ultra-low-latency AI scale-up network (SUN) that can efficiently distribute data across all network planes is critical. This document describes how to extend the Weighted Equal-Cost Multi- Path (WECMP) load-balancing mechanism, referred to as Fully Adaptive Routing Ethernet (FARE), which was originally designed for scale-out networks, to scale-up networks. |
| | 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)"). |
| | 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. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-14.txt |
| | Date: |
21/05/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
Section 8 of RFC 9334 defines "conceptual messages" as abstract messages exchanged by RATS roles such as Evidence, Attestation Results, Endorsements, and Reference Values. This document defines a "conceptual message" wrapper (CMW) format for any RATS conceptual message and describes a collection type that aggregates one or more CMWs into a single message. In addition, this document specifies a corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, and an X.509 extension. These mechanisms enable the embedding of enveloped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. Moreover, a Media Type and a CoAP Content-Format are defined for transporting CMWs over HTTP, MIME, CoAP, and other Internet protocols. |
| | Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| |
|
| |
| | BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
| |
| | draft-ietf-anima-brski-prm-22.txt |
| | Date: |
20/05/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). |
| | Clarification to processing Key Usage values during CRL validation |
| |
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, this document clarifies the requirement for relying parties to also verify the presence of the keyUsage extension in the CRL issuer's certificate. This check remediates a potential security issue that arises when relying parties accept a CRL which is signed by a certificate with no keyUsage extension, and therefore does not explicitly have the cRLSign bit asserted. |
| | Security Technical Specification for Smart Devices of IoT |
| |
|
As IoT adoption accelerates, securing smart devices emerges as a critical priority. This proposal outlines a comprehensive security framework spanning hardware integrity, system reliability, data protection, network safeguards, and management controls. The framework mandates secure hardware interfaces, firmware validation mechanisms, robust data encryption protocols, encrypted communication channels, and systematic security auditing processes to ensure end- to-end protection across device ecosystems. |
| | Technical Requirements for Secure Access and Management of IoT Smart Terminals |
| |
|
This specification outlines technical requirements for IoT smart terminal access management to address critical security challenges. The widely dispersed nature of IoT devices (including IP cameras, access control systems, and traffic monitoring units) complicates effective oversight while creating significant vulnerabilities during network authentication. The proposed framework combats unauthorized access and device impersonation through enhanced access control mechanisms, enabling real-time device monitoring and prompt detection of offline status - essential capabilities for maintaining secure and stable IoT network operations. |
| | Open Service Access Protocol for IoT Smart Devices |
| |
|
The proliferation of IoT technology has led to ubiquitous interconnectivity across devices and systems. However, industry-wide challenges persist due to heterogeneous data formats, incompatible device protocols, and fragmented service interfaces across IoT ecosystems. This technical specification establishes standardized communication protocols and control interfaces for IoT devices, targeting system design, testing, and interoperability research. By implementing a structured open service interconnection framework, it aims to streamline cross-system integration while reducing implementation redundancy and breaking down service barriers, ultimately accelerating industrial IoT advancement. |
| | Data Transmission Security of Identity Resolution in Industrial Internet |
| |
|
This draft examines data transmission security in Industrial Internet identity resolution systems. As pivotal infrastructure enabling secure cross-organizational sharing and intelligent correlation of heterogeneous data, these systems require robust security services during resolution processes. The analysis focuses on essential protective measures for identity resolution operations. |
| | Benchmarking Methodology for Source Address Validation |
| |
|
This document defines methodologies for benchmarking the performance of source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules to prevent source address spoofing, and have been implemented with many various designs in order to perform SAV in the corresponding scenarios. This document takes the approach of considering a SAV device to be a black box, defining the methodology in a manner that is agnostic to the mechanisms. This document provides a method for measuring the performance of existing and new SAV implementations. |
| | Remote Attestation with Exported Authenticators |
| |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. |
| | Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP). |
| |
| | draft-ietf-pce-sid-algo-19.txt |
| | Date: |
20/05/2025 |
| | Authors: |
Samuel Sidor, Zoey Rose, Shaofu Peng, Shuping Peng, Andrew Stone |
| | Working Group: |
Path Computation Element (pce) |
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document proposes an approach for informing PCEP peers about the SR-Algorithm associated with each SID used, as well as signaling a specific SR-Algorithm as a constraint to the Path Computation Element (PCE). The mechanisms for specifying an SR-Algorithm constraint allow for refined path computations that meet specific operational needs, such as low-latency or high-bandwidth paths based primarily on operator-defined criteria using Flexible Algorithms. Additionally, this document updates RFC 8664 and RFC 9603 to allow encoding of SR-Algorithm of specific SID in Explicit Route Object (ERO) subobjects. |
| | 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. |
| |
|
| |
| | Fixing the C-Flag in EARO |
| |
|
This document updates RFC 8928, “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks” (AP-ND), by updating the bit position for the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. |
| | Architecture and Framework for IPv6 over Non-Broadcast Access |
| |
|
This document presents an architecture and framework for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. |
| | Entering IPv6 Zone Identifiers in User Interfaces |
| |
|
This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874 and updates RFC 4007, RFC 7622 and RFC 8089. Discussion Venue This note is to be removed before publishing as an RFC. Discussion of this document takes place on the 6MAN mailing list (ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/ (https://mailarchive.ietf.org/arch/browse/ipv6/). |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a query to the probed node and the probed node responds to the query. The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the query, as it arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it allows the user to see how the network modified the query as it traveled from the probing node to the probed node. |
| | Ethernet VPN Virtual Private Wire Services Gateway Solution |
| |
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. |
| | The HTTP QUERY Method |
| |
|
This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. |
| | Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) |
| |
|
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535 identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. |
| | On-Path Telemetry YANG Data Model |
| |
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. |
| | 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. |
| | Signaling In-Network Computing operations (SINC) |
| |
| | draft-lou-rtgwg-sinc-04.txt |
| | Date: |
19/05/2025 |
| | Authors: |
David Lou, Luigi Iannone, Yizhou Li, Zhangcuimin, Kehan Yao |
| | Working Group: |
Individual Submissions (none) |
|
This memo introduces "Signaling In-Network Computing operations" (SINC), a mechanism to enable signaling in-network computing operations on data packets in specific scenarios like NetReduce, NetDistributedLock, NetSequencer, etc. In particular, this solution allows to flexibly communicate computational parameters, to be used in conjunction with the payload, to in-network SINC-enabled devices in order to perform computing operations. |
| | Efficient RDAP Referrals |
| |
|
This document describes how RDAP servers can provide HTTP "Link" header fields in RDAP responses to allow RDAP clients to efficiently determine the URL of related RDAP records for a resource. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-02.txt |
| | Date: |
19/05/2025 |
| | Authors: |
Benoit Claise, Luis Contreras, Jan Lindblad, Marisol Palmero, 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 and 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. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-12.txt |
| | Date: |
19/05/2025 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. |
| | Additional Email Address Extension for the Extensible Provisioning Protocol (EPP) |
| |
| | draft-ietf-regext-epp-eai-27.txt |
| | Date: |
19/05/2025 |
| | Authors: |
Dmitry Belyavsky, James Gould, Scott Hollenbeck |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
The Extensible Provisioning Protocol (EPP) does not natively support internationalized email addresses because the specifications for these addresses did not exist when EPP was developed. This document describes a command-response extension that adds support for associating an additional email address with an EPP contact object. That additional email address can be either an internationalized email address or an all-ASCII address. |
| | WIMSE Workload to Workload Authentication |
| |
| | draft-ietf-wimse-s2s-protocol-04.txt |
| | Date: |
19/05/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. |
| |
|
| |
| | Deterministic Networking (DetNet) Controller Plane Framework |
| |
|
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. |
| | HTTP Cache Groups |
| |
|
This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored response with one or more strings. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | Security for the NFSv4 Protocols |
| |
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the use of Access Control Lists, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881. |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-stephan-green-use-cases-01.txt |
| | Date: |
16/05/2025 |
| | Authors: |
Emile Stephan, Marisol Palmero, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos |
| | Working Group: |
Individual Submissions (none) |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-use-cases |
| | DS support for private DNSSEC algorithms |
| |
|
Extend the DS digest field of the DS record to identify the private DNSSEC algorithm of the DNSKEY matching the DS record. |
| | 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 analysis the dormant and flawed design. It defines some new flags to convey the maintenance information, which is not the role of IGP protocols and finally, there are several parts that are overlap with another precedent draft that discusses the corresponding contents more throughly. 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. |
| | Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability |
| |
| | draft-narajala-ans-00.txt |
| | Date: |
16/05/2025 |
| | Authors: |
Ken Huang, Vineeth Narajala, Idan Habler, Akram Sheriff |
| | Working Group: |
Individual Submissions (none) |
|
The proliferation of AI agents requires robust mechanisms for secure discovery. This document introduces the Agent Name Service (ANS), a novel architecture based on DNS addressing the lack of a public agent discovery framework. ANS provides a protocol-agnostic registry mechanism that leverages Public Key Infrastructure (PKI) certificates for verifiable agent identity and trust. The architecture features several key innovations: a formalized agent registration and renewal mechanism for lifecycle management; DNS-inspired naming conventions with capability-aware resolution; a modular Protocol Adapter Layer supporting diverse communication standards (A2A, MCP, ACP, etc.); and precisely defined algorithms for secure resolution. This specification describes structured communication using JSON Schema and includes a comprehensive threat analysis. The result is a foundational agent directory service protocol addressing the core challenges of secure discovery and interaction in multi-agent systems, paving the way for future interoperable, trustworthy, and scalable agent ecosystems. |
| | Remote Posture Assessment for Systems,Containers,and Applications at Scale |
| |
|
This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. |
| | Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512 |
| |
|
This document describe a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. |
| | Use of ML-DSA in TLS 1.3 |
| |
| | draft-ietf-tls-mldsa-00.txt |
| | Date: |
16/05/2025 |
| | Authors: |
Tim Hollebeek, Sophie Schmieg, Bas Westerbaan |
| | Working Group: |
Transport Layer Security (tls) |
|
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. |
| |
|
| |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-06.txt |
| | Date: |
15/05/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. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments "ietf-system-capabilities" YANG module defined in [RFC9196]. 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. |
| | YANG Metadata Annotation for Immutable Flag |
| |
|
This document defines a way to formally document an existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not proscriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. |
| | Distribution of Service Metadata in BGP FlowSpec |
| |
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST IP address. Its routes along with service metadata can be collected by a central controller. The controller may process the metadata and distribute the result to ingress routers using BGP FlowSpec. The service metadata can be used by ingress routers to make path selections not only based on the routing cost but also on the running environment of the edge services. This document describes a mechanism to distribute the information of the service routes and related service metadata using BGP FlowSpec. |
| | Design analysis of methods for distributing the computing metric |
| |
|
This document analyses different methods for distributing the computing metrics from service instances to the ingress router. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Computing-Aware Traffic Steering Working Group mailing list (cats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cats/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-cats-method-analysis. |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management on telecom and computer networks requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge graphs can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management (ITSM) Knowledge Graph (KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | ML-KEM Security Considerations |
| |
|
NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely. |
| | Cross-Domain Cloud-Native Resource Orchestration Framework with Dynamic Weight-Based Scheduling |
| |
|
The Distributed Resource Orchestration and Dynamic Scheduling (DRO- DS) standard in cross-domain cloud-native environments aims to address the challenges of resource management and scheduling in multi-cloud architectures, providing a unified framework for efficient, flexible, and reliable resource allocation. As enterprise applications scale, the limitations of single Kubernetes clusters become increasingly apparent, particularly in terms of high availability, disaster recovery, and resource optimization. To address these challenges, DRO-DS introduces several innovative technologies, including dynamic weight-based scheduling, storage- transmission-compute integration mechanisms, follow-up scheduling, real-time monitoring and automated operations, as well as global views and predictive algorithms. |
| | Secure Webhook Token (SWT) |
| |
|
The Secure Webhook Token (SWT) is a specialized JSON Web Token (JWT) format designed for securely authorizing and verifying webhook requests. It defines a set of claims to ensure that the token is explicitly tied to webhook events and that its integrity can be reliably validated by the recipient. A key feature of SWT is the introduction of a unique claim, webhook, which encapsulates webhook- specific information, such as the event type. By providing a structured and secure approach to webhook authentication, SWT aims to be a lightweight and flexible solution while maintaining compatibility with typical JWT structures. It is designed with the best practices in mind and may serve as a foundation for future standardization efforts. |
| | 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. |
| | Options representation in SCHC YANG Data Models |
| |
|
The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-07.txt |
| | Date: |
15/05/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). |
| |
|
| |
| | The IPv6 VPN Service Destination Option |
| |
|
This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment. |
| | CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-07.txt |
| | Date: |
14/05/2025 |
| | Authors: |
Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras |
| | Working Group: |
Global Routing Operations (grow) |
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. |
| | MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
| |
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-21.txt |
| | Date: |
14/05/2025 |
| | Authors: |
Alex Feng, Pierre Francois, Tianran Zhou, Thomas Graf, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enable higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. |
| | TLS Trust Anchor Identifiers |
| |
|
This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document draws on several years of operational experience to update the recommended process of Default Address Selection for Internet Protocol Version 6 (IPv6) defined in RFC6724, defining the concept of "known-local" Unique Local Address (ULA) prefixes that enable ULA-to-ULA communications within fd00::/8 to become preferred over both IPv4-IPv4 and GUA-to-GUA (Global Unicast Addresses) for local use. The document defines the means by which nodes can both identify and insert such prefixes into their address selection policy table. It also clarifies the mandatory, unconditional requirement for support for Rule 5.5 defined in Section 5 of RFC6724 and demotes the preference for 6to4 addresses. These changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios, and makes preference for IPv6 over IPv4 consistent in local site networks for both ULA and GUA prefixes. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. |
| | RTP Payload Format for Haptics |
| |
|
This memo describes an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS(MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP Payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for haptics/ hmpg, registered with IANA in RFC9695, did not include any required or optional parameters. This memo updates RFC9695 and the haptics/ hmpg registration to add optional parameters. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-25.txt |
| | Date: |
13/05/2025 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. |
| | Bundle Protocol Endpoint ID Patterns |
| |
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| | IAB AI-CONTROL Workshop Report |
| |
|
The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work. 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/intarchboard/draft-iab-ai-control-report. |
| | IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-ikev2-00.txt |
| | Date: |
13/05/2025 |
| | Authors: |
Steffen Klassert, Antony Antony, Tobias Brunner, Valery Smyslov |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specfies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in draft-klassert-ipsecme-eesp, provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-21.txt |
| | Date: |
13/05/2025 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri, Padma Pillay-Esnault |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. |
| | MPLS Network Actions for Network Resource Partition Selector |
| |
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provided the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. |
| | Scenarios and Challenges of Overlay Routing for SD-WAN |
| |
|
Overlay routing is essential during the enterprise networks' evolution from the interconnection among multiple on-premise branch sites to more advanced ones, such as the interconnection to multi- clouds. This document analyzes the technical requirements and challenges of overlay routing for SD-WAN in these scenarios. |
| | Trust and security considerations for Structured Email |
| |
|
This document discusses trust and security considerations for structured email and provides recommendations for message user agents on how to deal with structured data in email messages. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. |
| | Proof of Position for Auditor managed Endorsements |
| |
|
Some aspects of a device can not be intuited by the device itself. For instance, a router platform may have no way to know what color the case is, where in a cabinet it is located, or which electrical circuit it is connected to. This kind of information must be provided through an Endorsement: a statement from a third party. These statements may require human audiitors to inspect the device physically. But, which device is really in front of an auditor? This document describes a mechanism by which an auditor can make physical contact with a device and collect information to identify the device in a cryptographically strong manner. This protocol is not designed to run over Internet Protocol cabling, but rather over mechanisms such as USB cables, or serial consoles. |
| | AAuth - Agentic Authorization OAuth 2.1 Extension |
| |
|
This document defines the *Agent Authorization Grant*, an OAuth 2.1 extension for *confidential agent clients*—software or AI agents with long-lived identities—to request end-user consent and obtain access tokens via HTTP polling, Server-Sent Events (SSE), or WebSocket. It is heavily inspired by the core dance of the OAuth 2.0 Device Authorization Grant (RFC 8628) but is tailored for agents either long lived identities, and introduces scoped, natural-language descriptions and a reason parameter provided by the agent. |
| | Manual OAuth 2.0 Configuration Profile for Mail Clients |
| |
|
This document defines a lightweight and interoperable profile for configuring OAuth 2.0 authentication in mail clients using a small number of manually entered parameters. The profile targets public clients using PKCE and discovery endpoints, avoiding the need for dynamic client registration or hardcoded provider logic. The goal is to make secure OAuth 2.0-based authentication for IMAP/SMTP universally deployable and user-configurable. |
| | Manual OAuth 2.0 Configuration Profile for Mail Clients |
| |
|
This document defines a lightweight and interoperable profile for configuring OAuth 2.0 authentication in mail clients using a small number of manually entered parameters. The profile targets public clients using PKCE and discovery endpoints, avoiding the need for dynamic client registration or hardcoded provider logic. The goal is to make secure OAuth 2.0-based authentication for IMAP/SMTP universally deployable and user-configurable. |
| | A Technique for Quering the Designated Authoritative Server Directlly on the Local Resolver |
| |
| | draft-zhang-dnsop-zb-00.txt |
| | Date: |
13/05/2025 |
| | Authors: |
Bin Zhang, Yu Zhang, Jiankang Yao, Rongwei Yang, Yuming Feng |
| | Working Group: |
Individual Submissions (none) |
|
A DNS lookup usually requires the local resolver to start an iterative query process from the DNS root server to the bottom authoritative server. Attacks may occur at any level when querying authoritative servers. If the DNS recursive resolver operator can obtain the IP addresses of the authoritative servers for the queried domain, they may want to query the authoritative server directlly on the local resolver. In such a way, the resolver can start the iterative query process from the designated authoritative server, greatly decreasing the round-trip time, avoiding the attacks on the upper-level and preventing snooping by third parties of requests sent to upper-level authoritative servers. This document shows a technique for quering the designated authoritative server directlly on the local recursive server, at the cost of adding some operational fragility for the operator. |
| | 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 [RFC7996] 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. |
| | Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. |
| |
|
| |
| | Clarification of IPv6 Address Allocation Policy |
| |
|
This document specifies the approval process for changes to the IPv6 Address Space registry. It also updates RFC 7249. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-6man-addr-assign/. Discussion of this document takes place on the 6MAN Working Group mailing list (mailto:ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/. Subscribe at https://www.ietf.org/mailman/listinfo/ipv6/. |
| | Packed CBOR |
| |
| | draft-ietf-cbor-packed-15.txt |
| | Date: |
12/05/2025 |
| | Authors: |
Carsten Bormann, Mikolai Guetschow |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // This revision -15 is intended to serve as the input for the // 2025-05-14 CBOR interim meeting; it still has the tunables A/B/C // to be tuned. |
| | CBOR Extended Diagnostic Notation (EDN) |
| |
|
This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -17 is // intended to fully address the WGLC comments. It is intended for // use as a reference document for the CBOR WG interim meeting on // 2025-05-14. |
| | CBOR Common Deterministic Encoding (CDE) |
| |
| | draft-ietf-cbor-cde-11.txt |
| | Date: |
12/05/2025 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines the term "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders. |
| | Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 |
| |
| | draft-ietf-dtn-udpcl-01.txt |
| | Date: |
12/05/2025 |
| | Authors: |
Brian Sipos, Joshua Deaton |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of RFC7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unreliable transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. |
| | BGP Flow Specification for SRv6 |
| |
| | draft-ietf-idr-flowspec-srv6-07.txt |
| | Date: |
12/05/2025 |
| | Authors: |
Zhenbin Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, Shunwan Zhuang |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | DLEP Radio Band Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the frequency bands used by the radio. |
| | DLEP Radio Channel Utilization Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. |
| | RFC 3535,20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling |
| |
|
The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. |
| | Security and Privacy Implications of 3GPP AI/ML Services for 6G |
| |
|
This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) services. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. |
| | Architectural Considerations for Environmental Sustainability |
| |
|
This document describes several of the design tradeoffs involved in optimizing for sustainability along with the other common networking metrics such as performance and availability. |
| | Sustainability Considerations for Networking Protocols and Applications |
| |
|
Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementers sustainability- related advice and guidance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. |
| | Environmental Sustainability Terminology and Concepts |
| |
|
This document defines a set of sustainability-related terms and concepts to be used while describing and evaluating the negative and positive environmental sustainability impacts and implications of Internet technologies. |
| | SCONE Video Optimization Requirements |
| |
|
These are the requirements for the "Video Optimization" use-case for the SCONE topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-opsarea-rfc5706bis-01.txt |
| | Date: |
12/05/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, and introduces a requirement for an “Operational and Management Considerations” section in Internet-Drafts, before they are progressed as publication as RFCs. |
| | BGP Signaled MPLS Namespaces |
| |
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| | QUIC compression using SCHC |
| |
|
This document specifies a mechanism for applying Static Context Header Compression (SCHC) to QUIC (Quick UDP Internet Connections) packets. It leverages SCHC to compress both the QUIC packet header and the headers or type information of QUIC frames contained within the packet payload. This approach aims to significantly reduce QUIC overhead, optimizing bandwidth usage. This is particularly beneficial for valuable in bandwidth-sensitive scenarios like deep space communications. This document defines the SCHC architecture. |
| | Applying Attachmet Circuit and PE2PE YANG Data Model to dynamic policies Use Case |
| |
|
This document explores how existing IETF YANG data models can be applied to support a use case involving dynamic, time-scoped UCMP (Unequal Cost Multipath) policy enforcement across multiple network segments interconnecting Edge Cloud sites. The use case is motivated by periodic, high-volume data exchanges between distributed AI inference modules placed at geographically dispersed edge data centers. By mapping network requirements such as bandwidth, latency, and availability to relevant YANG models, including AC, TE Topology, SR Policy, and QoS models, this document serves as a practical exercise to evaluate the applicability and limitations of current IETF specifications. It highlights the need for cloud-initiated, time-bounded network policy activation and identifies potential gaps in model expressiveness, policy lifecycle handling, and API-level abstraction required for real-time cloud-network coordination. |
| | XRUDP eXtended Reliable UDP Protocol Specification |
| |
|
XRUDP (eXtended Reliable UDP) is a modern UDP-based transport protocol providing reliable, in-order, message-oriented delivery with congestion control, security, NAT traversal, and extensibility. It is designed for scenarios demanding reliable and efficient message delivery over unreliable networks, such as real-time signaling, IoT, gaming, and edge computing. This document specifies the XRUDP packet format, state machine, negotiation, and interaction with applications. |
| | OSPF Extensions for Precomputed Fast Reroute |
| |
|
This document proposes an enhancement to OSPF (Open Shortest Path First) that enables routers to precompute backup loop-free alternate (LFA) paths for fast reroute (FRR) in case of primary path failures. This mechanism improves convergence time and network stability by eliminating the delay associated with on-demand SPF recalculation during failure events. |
| | SRv6 for PPPoE Transport |
| |
|
This document presents a method of utilizing IPv6 underlay tunnels to transfer the PPPoE session information in broadband networks. By taking advantage of the programmability of SRv6 SIDs, it not only enables trusted authentication and secure access for broadband users but also meets the needs of operators to provide differentiated services to broadband users and flexibly deploy services. |
| | Congestion Control Based on SRv6 Path |
| |
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. |
| | Precision Time Protocol (PTP) Authentication Extension |
| |
|
Precision Time Protocol (PTP), as defined in IEEE 1588-2019, lacks cryptographic security mechanisms, exposing deployments to message spoofing, delay attacks, and timestamp manipulation. This document defines an optional Authentication TLV (AUTH_TLV) using modern Authenticated Encryption with Associated Data (AEAD) algorithms to ensure message integrity,authenticity, and replay protection. It also provides example configurations, implementation approaches, and test strategies. |
| | 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. |
| | RFC Editor Model (Version 3) |
| |
|
This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280. This document updates RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and 8729. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/ (https://datatracker.ietf.org/edwg/rswg/documents/). There is a repository for this draft at https://github.com/ paulehoffman/9280-updates (https://github.com/ paulehoffman/9280-updates). |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| |
|
| |
| | COSE Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. |
| | Fully-Specified Algorithms for JOSE and COSE |
| |
|
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFC 7518, RFC 8037, and RFC 9053. It deprecates polymorphic algorithms defined by RFC 8037 and RFC 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFC 7518 and RFC 9053. |
| | Path Tracing in SR-MPLS networks |
| |
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. |
| | 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. |
| | Unobtrusive End-to-End E-mail Signatures |
| |
|
This document deals with end-to-end cryptographically signed e-mail. It introduces a novel structure for signed e-mail that is designed to avoid creating any disturbance in legacy e-mail clients. This "unobtrusive" signature structure removes disincentives for signing e-mail. |
| | Terminal Access Controller Access-Control System Plus over TLS 1.3 (TACACS+ over TLS) |
| |
| | draft-ietf-opsawg-tacacs-tls13-21.txt |
| | Date: |
11/05/2025 |
| | Authors: |
Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The Terminal Access Controller Access-Control System Plus (TACACS+) protocol provides device administration for routers, network access servers, and other networked computing devices via one or more centralized TACACS+ servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC 8907. |
| |
|
| |
| | EVPN-VPWS Seamless Integration with L2VPN VPWS |
| |
|
This document presents a solution for migrating L2VPN Virtual Private Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) services. The solution allows the coexistence of EVPN and L2VPN services under the same point-to-point VPN instance. By using this seamless integration solution, a service provider can introduce EVPN into their existing L2VPN network or migrate from an existing L2VPN based network to EVPN. The migration may be done per pseudowire or per flexible-crossconnect (FXC) service basis. This document specifies control-plane and forwarding behaviors. |
| | Segment Routing over IPv6 Argument Signaling for BGP Services |
| |
|
RFC9252 defines procedures and messages for BGP Overlay Services for Segment Routing over IPv6 (SRv6) including Layer 3 Virtual Private Network, Ethernet Virtual Private Network, and Global Internet Routing. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifiers advertisements for BGP Overlay Service routes associated with SRv6 Endpoint Behaviors that support arguments. |
| | Update to the IANA CoAP Content-Formats Registration Procedures |
| |
|
This document updates RFC7252 regarding the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation. |
| | IP Tunnels in the Internet Architecture |
| |
|
This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet 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, IPv6 extension headers, and MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. |
| | A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane |
| |
|
This document defines a YANG data model that can be used to manage OSPF Extensions for Segment Routing over the MPLS data plane. |
| | EVPN multi-homing support for L3 services |
| |
|
This document introduces the utilization of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to enhance network availability and load balancing for various L3 services in EVPN. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: |
| | 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. |
| | Federated Authentication of Entities |
| |
| | draft-halen-fedae-01.txt |
| | Date: |
09/05/2025 |
| | Authors: |
Jakob Schlyter, Stefan Halen |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Federated Authentication of Entities (FedAE) framework, enabling secure machine-to-machine communication within a federation. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedAE ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. |
| | OAuth 2.0 App2App Browserless Flow |
| |
|
This document describes a protocol enabling native apps from any app publisher, using the [App2App] pattern, to achieve native user navigation without requiring a web browser. The native navigation is retained also when the Client uses any number of OAuth brokers to federate across trust domains, while offering highest levels of security. |
| | Applying COSE Signatures for YANG Data Provenance |
| |
| | draft-ietf-opsawg-yang-provenance-00.txt |
| | Date: |
09/05/2025 |
| | Authors: |
Diego Lopez, Antonio Pastor, Alex Feng, Ana Perez, Henk Birkholz, Sofia Garcia |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| | Cursor-based Pagination of SCIM Resources |
| |
|
This document defines additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM implementations that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
| |
| | draft-ietf-spring-stamp-srpm-18.txt |
| | Date: |
09/05/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 procedures for Performance Measurement in SR networks using the Simple Two-Way Active Measurement Protocol (STAMP) 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 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. |
| | A YANG Data Model for the RFC 9543 Network Slice Service |
| |
|
This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. |
| |
|
| |
| | BGP Flowspec for IETF Network Slice Traffic Steering |
| |
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic Flow Specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be performed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). |
| | Authorized update to MUD URLs |
| |
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| | Ownership and licensing statements in YANG |
| |
|
This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | Clarification and enhancement of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-22.txt |
| | Date: |
08/05/2025 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document updates RFC7030, Enrollment over Secure Transport (EST), clarifying how the Certificate Signiing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object IDs (OID) and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. RFC7030 (EST) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. As a result, there was not universal understanding of what was specified. This document clarifies the encoding rules. This document therefore also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subject Distinguished Name (DN). |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
| |
| | draft-ietf-lamps-x509-slhdsa-07.txt |
| | Date: |
08/05/2025 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also described. |
| | LISP L2/L3 EID Mobility Using a Unified Control Plane |
| |
| | draft-ietf-lisp-eid-mobility-16.txt |
| | Date: |
08/05/2025 |
| | Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | Discovery Of Restconf Metadata for Source-specific multicast |
| |
|
This document defines DORMS (Discovery Of Restconf Metadata for Source-specific multicast), a method to discover and retrieve extensible metadata about source-specific multicast channels using RESTCONF. The reverse IP DNS zone for a multicast sender's IP address is configured to use SRV resource records to advertise the hostname of a RESTCONF server that publishes metadata according to a new YANG module with support for extensions. A new service name and the new YANG module are defined. |
| | Circuit Breaker Assisted Congestion Control |
| |
|
This document specifies Circuit Breaker Assisted Congestion Control (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate metadata about multicast channels from senders to intermediate network nodes or receivers. The circuit breaker behavior is defined as a supplement to receiver driven congestion control systems, to preserve network health if misbehaving or malicious receiver applications subscribe to a volume of traffic that exceeds capacity policies or capability for a network or receiving device. |
| | A Framework for a Network Anomaly Detection Architecture |
| |
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. |
| | Semantic Metadata Annotation for Network Anomaly Detection |
| |
|
This document explains the motivation for defining semantic metadata annotations to help testing, validating and comparing Outlier and Symptom detection systems. These semantic annotations can be supported by supervised and semi-supervised machine learning algorithms and enable data exchange among network operators, vendors and academia, making anomalies apprehensible for humans. The proposed semantics uniforms the network anomaly data exchange between operators and vendors to improve their Service Disruption Detection Systems. |
| | An Experiment: Network Anomaly Lifecycle |
| |
|
Network Anomaly Detection is the act of detecting problems in the network. Accurately detect problems is very challenging for network operators in production networks. Good results require a lot of expertise and knowledge around both the implied network technologies and the connectivity services provided to customers, apart from a proper monitoring infrastructure. In order to facilitate network anomaly detection, novel techniques are being introduced, including programmatical, rule-based and AI-based, with the promise of improving scalability and the hope to keep a high detection accuracy. To guarantee acceptable results, the process needs to be properly designed, adopting well-defined stages to accurately collect evidence of anomalies, validate their relevancy and improve the detection systems over time, iteratively. This document describes a well-defined approach on managing the lifecycle process of a network anomaly detection system, spanning across the recording of its output and its iterative refinement, in order to facilitate network engineers to interact with the network anomaly detection system, enable the "human-in-the-loop" paradigm and refine the detection abilities over time. The major contributions of this document are: the definition of three key stages of the lifecycle process, the definition of a state machine for each anomaly annotation on the system and the definition of YANG data models describing a comprehensive format for the anomaly labels, allowing a well-structured exchange of those between all the interested actors. |
| | OpenPGP Example Keys and Certificates",Bjarni Einarsson,"juga |
| |
|
The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. |
| | Stateless OpenPGP Command Line Interface |
| |
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. |
| | SRv6 Deployment and Operation Problem Summary |
| |
| | draft-liu-srv6ops-problem-summary-05.txt |
| | Date: |
08/05/2025 |
| | Authors: |
Yisong Liu, Dan Voyer, Thomas Graf, Zoltan Miklos, Luis Contreras, Nicolai Leymann, Linjian Song, Satoru Matsushima, Chongfeng Xie, Xinxin Yi |
| | Working Group: |
Individual Submissions (none) |
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-01.txt |
| | Date: |
08/05/2025 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using SCONE protocol signalling, it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | 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. |
| | OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents |
| |
|
This specification extends the OAuth 2.0 Authorization Framework [RFC6749] to enable AI agents to securely obtain access tokens for acting on behalf of users. It introduces the *requested_actor* parameter in authorization requests to identify the specific agent requiring delegation and the *actor_token* parameter in token requests to authenticate the agent during the exchange of an authorization code for an access token. The flow can be initiated by a resource server challenge, ensuring that user consent is obtained dynamically when access is attempted. This extension ensures secure delegation with explicit user consent, streamlines the authorization flow, and enhances auditability through access token claims that document the delegation chain from the user to the agent via a client application. |
| | ISIS Hierarchical SNPs |
| |
|
The document introduces an optional, new type of SNPs called Hierarchical SNP (HSNP) that can compress the traditional CSNPs exchange into a variant of merkle tree, hence allowing to support very large databases and adjacency numbers. Such an approach should lead in case of inconsistencies to much faster re-synchronization since only a subset of packets compared to full scale CSNP exchange is necessary to correct the entropy present. |
| | Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV) |
| |
|
This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). |
| | Deterministic Upstream Neighbor Selection for PIM Joins |
| |
|
In densely interconnected networks, a PIM node may have many choices as to what upstream neighbor to send a JOIN message to, for a given source and group. This document describes a mechanism for multiple nodes (e.g., leaf nodes in a data center) to pick the same upstream node (e.g., spine node) to avoid redundant traffic flows. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-12.txt |
| | Date: |
08/05/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. |
| | Revision of the RPKI Validation Algorithm |
| |
|
This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6487. This document updates RFC 9582. This document obsoletes RFC 8360. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes the mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. A list of resource-aware SIDs can be used to allow an SR Policy to use a specific set of network resources, and a group of resource-aware SIDs can be used to represent a virtual network with a specific set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| |
|
| |
| | EVPN Support for L3 Fast Convergence and Aliasing/Backup Path |
| |
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. |
| | 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. |
| | Multicast YANG Data Model |
| |
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast streams. It provides a management view for network administrators to obtain information about multicast services. |
| | Asymmetric Manifest Based Integrity |
| |
|
This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. |
| | Security and Privacy Considerations for Multicast Transports |
| |
|
Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. 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/squarooticus/draft-krose-multicast-security. |
| | BGP Route Type Capability |
| |
|
BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-01.txt |
| | Date: |
07/05/2025 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | Means of Compliance for DRIP Entity Tags as UAS RID Identifiers |
| |
|
This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirement for the development of the RESTful Provisioning Protocol (RPP). |
| | 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. |
| |
|
| |
| | CoAP Management Interface (CORECONF) |
| |
| | draft-ietf-core-comi-20.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-00.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
DNS Delegation (deleg) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | YANG Data Model for BGP about RPKI |
| |
|
This document defines YANG data models for configuring and managing BGP information about Resource Public Key Infrastructure (RPKI). |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-01.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane |
| |
| | draft-ietf-isis-sr-yang-31.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Stephane Litkowski, Yingzhen Qu, Acee Lindem, Helen Chen, Jeff Tantsura |
| | Working Group: |
Link State Routing (lsr) |
|
This document defines a YANG data model that can be used to manage IS-IS Extensions for Segment Routing over the MPLS data plane. |
| | Optional IS-IS Fragment Timestamping |
| |
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for the high-speed and high-throughput data transmission within completion time in High Performance Wide Area Network (HP-WAN). It particularly enhances the congestion control and facilitates the functionalities for the host to collaborate with the network to perform rate negotiation, such as QoS policy, admission control, traffic scheduling and so on. |
| | Getting Nameservers in the New Delegation Protocol |
| |
|
The DELEG Working Group has chosen a base protocol that describes how resolvers will be able to get a new DNS resource record to create a new process for DNS delegation. After a resolver gets this new type of record, it needs to know how to process the record in order to get a set of nameservers for a zone. This document lists many of the considerations for that process, including many open questions for the DELEG Working Group. More considerations and open questions might be added in later versions of this draft. Note that this draft is _not_ intended to become an RFC. It is being published so that the DELEG Working Group has a place to point its efforts about how resolvers get nameservers for a zone while it continues to work on choosing a base protocol. The work that results from this might be included in the base protocol specification, or in a new draft authored by some of the many people who have done earlier work in this area. |
| | SR Policy Extensions for energy efficiency |
| |
|
[draft-liu-spring-sr-energy-efficiency-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document details the extensions to the BGP SR Policy and BGP-LS SR Policy to encapsulate the energy consumption information for each segment list of the SR Policy candidate paths, enabling its utilization in the route selection process. |
| | Standard Communication with Network Elements (SCONE) Protocol |
| |
| | draft-thoji-scone-protocol-00.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Standard Communication with Network Elements (scone) |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. |
| | TCP ACK Rate Request Option |
| |
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. |
| |
|
| |
| | Meticulous Keyed ISAAC for BFD Optimized Authentication |
| |
|
This document describes a new BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the the "Up" state. |
| | Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. |
| | Structured Error Data for Filtered DNS |
| |
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| | Performance Measurement with Asymmetrical Traffic Using STAMP |
| |
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables control of the length and/or number of reflected packets during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further request. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. |
| | YANG Data Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, 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. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-41.txt |
| | Date: |
05/05/2025 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Computing Aware Traffic Steering (CATS) with Generic Metric |
| |
|
Steering traffic for computing-related services considering computing resources and circumstances is discussed in CATS WG. Correspondingly, publishing services and updating computing conditions turns out to be a significant issue. It SHOULD be realized that multiple same common metrics are required from both network and service instances in order to evaluate overall performance and further achieve and fulfill appropriate traffic steering and scheduling. Therefore, an implementation for distributed CATS with generic metrics delivery and distribution based on BGP is proposed and discussed in this draft. |
| | Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case |
| |
|
This document explores how existing IETF YANG data models, specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and Traffic Engineering (TE) topology data models, can be applied to support a use case involving dynamic AI model placement at Edge Cloud sites. The use case involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG data models to retrieve and request specific services objectives such as bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model applicability and identify gaps, if any. |
| | Framework,Use Cases and Requirements for AI Agent Protocols |
| |
|
AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. |
| | Reservation of f000::/4 for Structured Internal-Use IPv6 Addressing |
| |
|
This document proposes the reservation of the IPv6 address block f000::/4 for structured internal-use networking. This allocation extends the concepts of Unique Local Addresses (ULAs) as defined in RFC 4193, acknowledging the growing demand for a larger, more hierarchically organised, and clearly non-internet-routable address space for internal networks. The reservation of f000::/4 would prevent future conflicts with public allocations and provide operational clarity to large-scale, privacy-focused, or non-public infrastructures. |
| | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. |
| | Task Binding and In-Band Provisioning for DAP |
| |
|
An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-03.txt |
| | Date: |
05/05/2025 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| | 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). |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. 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/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | 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. |
| | Agreements To Fix Forwarding |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. |
| | Distribution of Source Address Validation State in BGP |
| |
|
Source Address Validation (SAV) is a technique that can be used to mitigate source address spoofing. draft-huang-savnet-sav-table codifies the concept of source address validation on a per-incoming interface basis, the validation mode, and the traffic handling policy as a "SAV Table". This document defines a mechanism for distributing logical SAV Tables in BGP. This mechanism is addresses inter-domain SAV use cases. These SAV Tables may be used to implement appropriate device-specific validation for source addresses. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptographic algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |
| | Using 802.1AB (LLDP) for IETF LSVR neighbor discovery and configuration |
| |
|
IEEE Std 802.1AB, known as the Link Layer Discovery Protocol (LLDP), can be applied to LSVR neighbor discovery and configuration. This can be achieved by using a nearest router group address as the LLDP Scope MAC Address to target LSVR interfaces while advertising a set of LSVR-specific LLDP TLVs. These LSVR-specific TLVs are defined using LLDP Organizationally Specific TLVs, as specified by LLDP for use by individual organizations to allow them to define their own Type-Length-Value (TLV) objects for exchange over the LLDP protocol. The IETF Organizationally Specific TLVs for LSVR can be encoded using the IETF IANA OUI (RFC 7042). This document provides an overview of applying LLDP to LSVR neighbor discovery and configuration and specifies the IETF Organizationally Specific TLVs that support link discovery for LSVR routers. In addition, a brief discussion of the use of IEEE Connectivity Fault Management (CFM) as specified in IEEE Std 802.1Q-2022 cl 18-22 for link liveliness is included. |
| | Information and Data Models for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-07.txt |
| | Date: |
01/05/2025 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines an information model and a corresponding YANG data model for packet discard reporting. The information model provides an implementation-independent framework for classifying packet loss to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this framework for network elements. |