| |
|
| |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. |
| | A YANG Data Model for Network Tester Management |
| |
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-25.txt |
| | Date: |
07/04/2026 |
| | Authors: |
Hannes Tschofenig, Michael Jones, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. |
| | Integration of DNS Domain Names into Application Environments: Motivations and Considerations |
| |
|
This document describes considerations when integrating a DNS domain name into an application environment. Goals of this document include minimizing conflicts between the global DNS and applications that integrate with the global DNS, providing a consistent user experience (unique identifier across environments), and avoiding impacts to the security, stability, and resiliency of the global DNS. While all sources of potential concern cannot be enumerated in one document, accounting for at least the considerations discussed here should improve the security posture of both the global DNS and integrating applications. |
| | BGP Operations and Security |
| |
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. It is important to understand the security and reliability requirements that can and should be met to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publication of RFC7454, changes in operational practice have taken place, which are partially conflicting with the advice given in RFC7454. This document obsoletes RFC7454, and provides less implementation-specific best practices, with the goal of being less prone to becoming outdated or conflicting with changed operational practices. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | SCION Data Plane |
| |
|
This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Intra-domain SAVNET Support via IGP |
| |
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. |
| | Adaptive Routing Framework |
| |
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. |
| | Knowledge Graph Framework for Network Operations |
| |
| | draft-mackey-nmop-kg-for-netops-04.txt |
| | Date: |
07/04/2026 |
| | Authors: |
Michael Mackey, Benoit Claise, Thomas Graf, Holger Keller, Dan Voyer, Paolo Lucente, Ignacio Martinez-Casanueva |
| | Working Group: |
Individual Submissions (none) |
|
This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. 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/mike-mackey. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | Post-Quantum Enhancements to TLS-Based EAP Methods |
| |
|
This document proposes enhancements to TLS-based EAP methods, including the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS), EAP Tunneled TLS (EAP-TTLS), Protected EAP (PEAP), and EAP Tunnel Method (TEAP), to incorporate post-quantum cryptographic mechanisms. It also addresses challenges related to large certificate sizes and long certificate chains, as identified in [RFC9191], and provides recommendations for integrating PQC algorithms into TLS-based EAP deployments. |
| | Community considerations on DNS WG structures at IETF |
| |
|
There has been an increasing level of discussion within the IETF about the best Working Group (WG) structures for handling the wide array of DNS work being conducted within the IETF. As part of community consultation, a team coordinated by Wes Hardaker was asked to gather information from the community at large through e-mail, hallway discussions, and meetings and create a small team to discuss potential structural changes to be shared with the community. This document is the result of that effort. The outcome of the consultation is retained for historic reference. |
| | JMAP Blob Extensions |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. The JMAP blob extension (RFC9404) added additional ways to create and access blobs by making inline method calls within a standard JMAP request. This extension adds more methods to work with blobs, including handling large blobs by processing them in chunks (building on RFC9404's blob construction support), and providing server-side blob conversion operations: image format conversion, archive creation and extraction (zip, tar, cpio), compression and decompression, and delta/patch operations. |
| | NMSF - Neural Video Codec Packaging for MOQT Streaming Format |
| |
|
This document updates the MOQT Streaming Format (MSF) by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding Neural Video Codec (NVC) packaged media to MSF. NVC codecs use learned neural network transforms for video compression, and their bitstreams require a distinct packaging model from traditional block-based codecs. NMSF maps neural keyframes (Intra) and delta frames (Inter) onto MoQ Groups and Objects, and introduces a multi-track model that separates hyperprior side information from latent bitstreams for priority-aware delivery. This enables real-time neural video streaming over any standard MoQ relay. |
| | Discovery of Model Context Protocol Servers via DNS TXT Records |
| |
|
This document defines a DNS-based mechanism for the discovery of Model Context Protocol (MCP) servers. A TXT resource record published at the underscore-prefixed label _mcp. advertises the presence, endpoint URL, transport protocol, cryptographic identity, and capability profile of an MCP server associated with a domain name. The mechanism complements existing HTTPS-based discovery (.well-known/mcp/server-card.json) by providing a lightweight, resolver-cached bootstrap that requires no HTTPS round- trip. The design follows the precedent established by DKIM [RFC6376], SPF [RFC7208], DMARC [RFC7489], and MTA-STS [RFC8461], all of which use DNS TXT records at underscore-prefixed labels to advertise domain-scoped policy and service metadata. |
| | Agent Context Compression Protocol (ACCP) |
| |
|
This document specifies the Agent Context Compression Protocol (ACCP), a semantic encoding and context management protocol for communication between AI agents within agentic harnesses. ACCP defines a compact message format, intent ontology, state compression strategy, and codec interface that collectively reduce token consumption by 60-90% compared to natural language or standard JSON messaging. ACCP is designed to complement existing protocols (MCP, A2A) and is transport-agnostic. |
| | Anonymous Bot Authentication: Authorization and Rate Limiting for Web Agents |
| |
|
Automated agents ("bots") represent a large fraction of the traffic to many Web sites. In some cases, this traffic is desired, in others undesired, and in yet others, desired as long as it remains within certain rate limits. This memo describes Anonymous Bot Authentication (ABA), a system that allows Web site operators to distinguish wanted from unwanted traffic, while not tying a given request to a specific sender. |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-05.txt |
| | Date: |
07/04/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, Jishnu Roy, Jeff Haas, Hongwei Liu, Di Ma |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| | 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. DTLS 1.3 uses the same plaintext size limit. This document defines a TLS extension that allows endpoints to advertise larger per-direction maximum inner plaintext sizes, up to 2^30 - 256 bytes, while reducing overhead in TLS 1.3 and DTLS 1.3 record headers. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |
| |
|
| |
| | 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 registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -22 is // intended to present a complete specification that can be used to // confirm the results of the 2026-04-01 CBOR interim. This includes // extending inline comments to encompass C-style comments, and end- // of-line comments to encompass C++-style comments. |
| | 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. |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document specifies the procedure for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for a Stub Link, as well as three new type-length-values (TLVs) for the BGP-LS Stub Link descriptor. These BGP-LS extensions enable Software- Defined Networking (SDN) controllers to retrieve network topology across inter-AS environments. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by the BGP-LS protocol. |
| | Use of Variable-Length Output Pseudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFCs 5723, 6617, 6631, 7296, 8784, 9370, 9838, 9867 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. |
| | VLSM Tree Routing Protocol |
| |
|
This is a light weight routing protocol applicable inside a network that appears in the form of a tree and distribution of address space takes place with the approach of VLSM. It is based on setting default route inside VLSM tree. With this approach, routing information of the external world need not be passed down to the VLSM tree. Thus, load inside a router gets reduced substantially. This document includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. |
| | RIFT in Dragonfly Topologies |
| |
|
RIFT extensions for dragonfly topologies. |
| | LISP Multicast Deployment Experience |
| |
|
We present our experiences in supporting deployments of LISP Multicast using unicast and multicast underlays. This document details design considerations that can be useful for anyone interested in deploying LISP multicast services over IP networks. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction, referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of residual bit error rate within the "Extra Padding" TLV of STAMP packets. |
| | ISIS Hierarchical SNPs |
| |
|
The document presents an optional new type of SNP called a Hierarchical SNP (HSNP). When feasible, it compresses traditional CSNP exchanges into a Merkle tree-like structure, which speeds up synchronization of large databases and adjacency numbers while reducing the load from regular CSNP exchanges during normal operation. |
| | Best Current Practice for ROA Issuance Restrictions in RPKI |
| |
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It RECOMMENDS that a parent Certification Authority (CA) void issuing ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are expected to support these practices by appropiate warning. |
| | AERO/OMNI Base Specification Amendments (Volume 1) |
| |
|
The Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface functional specifications have reached a level of maturity ready for advancement in the RFC publication process. Updates to the base specifications are documented in this first amendment and any additional future amendments as necessary. |
| | Problem Statement: Network-Layer Infrastructure for Autonomous Agent Communication |
| |
|
AI agents --- autonomous software entities capable of reasoning, planning, and executing tasks --- are an increasingly important class of network participant. Current agent communication protocols operate exclusively at the application layer over HTTP, assuming the existence of stable endpoints, DNS names, and centralized infrastructure. No existing standard provides network-layer identity, addressing, or transport for agents. This document describes the problem space and identifies requirements for a network-layer infrastructure that would give agents first-class network citizenship, independent of the web infrastructure designed for human users. |
| | Pilot Protocol: An Overlay Network for Autonomous Agent Communication |
| |
|
This document specifies Pilot Protocol, an overlay network that provides autonomous AI agents with virtual addresses, port-based service multiplexing, reliable and unreliable transport, NAT traversal, encrypted tunnels, and a bilateral trust model. Pilot Protocol operates as a network and transport layer beneath application-layer agent protocols such as A2A and MCP. It encapsulates virtual packets in UDP datagrams for transit over the existing Internet. The protocol gives agents first-class network citizenship --- stable identities, reachable addresses, and standard transport primitives --- independent of their underlying network infrastructure. |
| | A Deployment Profile for DKIM2 via Milter Interface |
| |
|
This document defines a deployment profile for DomainKeys Identified Mail v2 (DKIM2) that is implementable via the existing milter interface without modifications to Mail Transfer Agent (MTA) core software. It identifies a mandatory core profile (DKIM2-core) covering envelope binding, chain of custody, header accountability, replay prevention and DSN authentication and an optional extended profile (DKIM2-extended) covering body recipes and Message-Instance headers. The separation is motivated by deployment realism: the core profile addresses the primary threat models identified in the DKIM2 motivation document and is deployable incrementally across heterogeneous infrastructure, including small operators, universities and research institutions, using the same milter-based deployment model that has proven effective for DKIM1 and ARC. |
| | OMP Domain Profile: AI Governance and Accountability Evidence for US Housing Finance Under FHFA Bulletin 2025-16 and GSE AI/ML Model Risk Governance |
| |
| | draft-veridom-omp-fhfa-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI and machine learning (ML) systems deployed in US housing finance contexts subject to the Federal Housing Finance Agency (FHFA) Bulletin 2025-16 (effective March 3, 2026), which establishes a comprehensive AI governance framework for Fannie Mae, Freddie Mac, and the Federal Home Loan Banks (the GSEs), requiring transparency, accountability, and ethical stewardship for AI/ML systems used in housing finance decisions. The profile -- designated HomeMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the AI governance evidence requirements of FHFA Bulletin 2025-16, including per-decision accountability, named individual responsibility, model risk governance documentation, fair lending evidence, and representation and warranty compliance for mortgage origination, credit decisioning, property valuation, and loan servicing. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | Agent Identity Framework: Trust and Identity for Autonomous AI Agents |
| |
|
Autonomous artificial intelligence (AI) agents are increasingly performing actions that were previously the exclusive domain of authenticated human users: initiating financial transactions, querying regulated data, invoking external tools, and coordinating with other agents. Internet protocols designed for human-operated clients lack primitives to answer three fundamental questions about any autonomous action: which agent performed it, whether the agent was authorized to perform it, and whether the resulting evidence is independently verifiable. This document defines a framework for agent identity and trust enforcement on the Internet. It enumerates the gaps between current Internet standards and the requirements of autonomous agent systems, introduces a five-layer model (identity, authorization, attestation, evidence, trust) that separates concerns that are currently conflated, and outlines mechanisms to close specific gaps. The framework is intended to guide future Standards Track work and to provide a common vocabulary for researchers, implementers, and regulators. This document is informational. It does not define a wire protocol. It references existing Internet-Drafts and specifications that instantiate individual mechanisms within the framework. |
| | Knowledge Units for Multi-Model Deliberation |
| |
|
This document defines the Knowledge Unit (KU) format for representing verified knowledge produced through structured multi-model deliberation. A Knowledge Unit captures the question asked, the models that participated, the consensus achieved, the points of agreement and disagreement, and the cryptographic receipts that bind each deliberation round to an independently verifiable chain. The format addresses the epistemic integrity gap in LLM-maintained knowledge bases: how to prove that knowledge was derived through a rigorous process, that disagreement was preserved rather than smoothed away, and that the record has not been tampered with. This specification complements draft-farley-acta-signed-receipts, which defines the receipt format and verification protocol used to sign individual deliberation rounds. |
| | OMP Domain Profile: AI Governance Evidence Under Singapore's Model AI Governance Framework,MAS FEAT Principles,and the ASEAN Guide on AI Governance and Ethics |
| |
| | draft-veridom-omp-sgapac-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in Singapore and the ASEAN region subject to the Singapore Model AI Governance Framework (Second Edition, 2020), the Monetary Authority of Singapore (MAS) FEAT Principles for financial services AI, and the ASEAN Guide on AI Governance and Ethics (2024). The profile -- designated SingapureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate the per-decision accountability evidence required by Singapore's model AI governance framework, satisfy the MAS FEAT Principles' named accountability and explainability requirements, and align with the ASEAN Guide's human oversight and consumer protection governance standards. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | AIPREF Vocabulary Exclusions |
| |
|
This document proposes an update to the AI preferences vocabulary [VOCAB] in order to establish protected uses (exclusions). |
| | OMP Domain Profile: Cross-Sector High-Risk AI Accountability Under the Colorado Artificial Intelligence Act (SB 24-205) and Alignment with NIST AI RMF 1.0 |
| |
| | draft-veridom-omp-coloai-00.txt |
| | Date: |
06/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI systems subject to the Colorado Artificial Intelligence Act (SB 24-205, effective June 1, 2026), which requires deployers of high-risk AI systems in consequential decisions affecting Colorado consumers to implement risk management programmes, provide consumer disclosures, conduct impact assessments, and implement discrimination mitigation measures. The profile -- designated ColoradoMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the Colorado AI Act's per-decision accountability obligations and align with the NIST AI RMF 1.0, providing a unified cross-sector accountability evidence architecture for the six Colorado AI Act consequential decision domains. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | Fast Latency and Congestion Notification |
| |
|
This document describes a standard-based method for fast latency and congestion notification. By combining in-network telemetry and source routing, it enables a source node to acquire a path's latency and congestion status in less than half baseline RTT. The more timely and accurate telemetry data allow the source node to apply more effective traffic steering and congestion control actions. The method is applicable to both WAN and DCN, and can be realized through existing IETF standards. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. |
| | Host key update mechanism for SSH |
| |
|
This document describes an extension to allow a Secure Shell (SSH) server to inform a client of the full set of host keys it supports. This may be used for graceful host key rotation and to provide keys for additional signature algorithms to the client, supporting algorithm agility. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. |
| |
|
| |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New LISP use cases increase the amount of state that needs to be communicated and challenge the scalability of the system when using the UDP exchange. This document introduces the use of a reliable transport for ETR to Map-Server communications in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | Verified Email Identity Framework (VEIF) |
| |
|
This document defines the Verified Email Identity Framework (VEIF), a mechanism for associating a cryptographically verifiable real- world identity with an email message. VEIF complements existing email authentication technologies such as SPF, DKIM, and DMARC by providing a higher-level identity assurance layer. |
| | The AI Visibility Lifecycle Framework |
| |
|
This document describes the 11-Stage AI Visibility Lifecycle, a stage-based observational framework describing how websites achieve visibility within AI discovery, comprehension, trust, and human exposure systems. The framework identifies three distinct phases -- AI Comprehension (Stages 1-5), Trust Establishment (Stages 6-8), and Human Visibility (Stages 9-11) -- through which domains progress from initial AI crawling to sustainable human-facing visibility. |
| | Agent Identity,Trust and Lifecycle Protocol (AITLP) |
| |
|
This document defines the Agent Identity, Trust and Lifecycle Protocol (AITLP), a protocol for autonomous software agents operating within organizational boundaries. AITLP specifies agent identity and naming conventions, hierarchical mandate enforcement, lifecycle state management, inter-agent trust verification, ontological scope constraints, certificate-based authentication, and generational knowledge transfer via Agent Legacy Mode (ALM). The protocol enables agents to operate autonomously while remaining auditable, revocable, and organizationally bounded. AITLP focuses on boundaries -- what an agent is not permitted to do and how that is enforced -- complementing capability-focused specifications such as MCP, A2A, and ANS. Unlike those specifications, AITLP defines not a tool or a communication channel, but an organizational actor: an agent with a declared identity, a bounded mandate, a managed lifecycle, and a cryptographically enforced scope of authority. |
| | Deprecating the FRAG Field in SOCKS5 |
| |
|
This document updates RFC 1928 by formally deprecating the FRAG (Fragment) field in the SOCKS5 UDP ASSOCIATE request header. It mandates that the FRAG field MUST be set to X'00' by clients and that proxies MUST drop any SOCKS5 UDP packets containing a non-zero FRAG value. This change aligns the SOCKS5 protocol with modern Internet engineering practices regarding UDP fragmentation (BCP 227), simplifies proxy implementations, and eliminates a vector for resource exhaustion attacks. |
| | The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity |
| |
|
This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV is designed to enable an agent to prove that it is running an authorized model and policy without exposing sensitive data. The protocol is intended to compose with existing RATS attestation mechanisms and to support exercise-time re-attestation requirements. The protocol defines a common envelope format (CBOR/CDDL), message types for attestation request/response, and a threat model that separates identity binding integrity from behavioral continuity. Behavioral continuity is treated as a separate requirement class addressed via exercise-time checks and execution receipts (e.g., SCITT composition), not by PTV alone. Example use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios. |
| | OMP Domain Profile: FCA Consumer Duty,SM&CR Accountability,and AI Governance Evidence for UK Retail Financial Services |
| |
| | draft-veridom-omp-fca-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in UK retail financial services contexts subject to the Financial Conduct Authority (FCA) Consumer Duty (PS22/9, effective July 31, 2023), the Senior Managers and Certification Regime (SM&CR), and the FCA's emerging AI accountability framework as informed by the Mills Review (2026) and the FCA's research on algorithmic decision-making. The profile -- designated DutyMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the evidence requirements for Consumer Duty outcome testing, SM&CR named accountability, and FCA supervisory examination of AI-assisted retail financial services decisions. The profile covers the four Consumer Duty outcome areas and FCA agent distribution oversight. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | OMP Domain Profile: AI Liability Insurance Underwriting and Parametric Claims Evidence |
| |
| | draft-veridom-omp-aiins-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in contexts covered by AI liability insurance policies, including AI performance warranties, AI errors and omissions coverage, and coordinated AI liability structures. The profile -- designated InsureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate per-decision Proof-Points that function as objective parametric trigger data for AI liability insurance claims, and provide independently verifiable underwriting evidence that reduces claims ambiguity and supports premium differentiation. The InsureMark profile addresses the primary gap in current AI liability insurance underwriting: policies are currently issued based on model-level performance assessments, but claims arise at the level of individual AI decisions. No current AI liability insurance product requires or receives per-decision cryptographic evidence. This profile specifies the technical architecture by which OMP Proof- Points close this gap. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | External Time Anchor Profile for SCITT Transparency Services |
| |
|
SCITT Transparency Services record signed statements in append-only logs and issue receipts that include an internal timestamp derived from log inclusion. This timestamp depends on the service operator's own clock and log infrastructure. It cannot be independently verified by a party that does not trust the operator. This document defines an optional, additive profile that attaches an externally verifiable time anchor to an existing Origin Record. The anchor is a standard OpenTimestamps (.ots) proof ultimately committed to the Bitcoin blockchain. The resulting proof is self-contained and portable: it can be verified by any party holding the original file and the .ots proof, without contacting the Transparency Service, the anchoring service, or any trusted authority. No changes to SCITT protocols, signed statement formats, or receipt structures are required. |
| | OMP Domain Profile: Clinical AI Decision Accountability Under Joint Commission/CHAI Guidance,California SB 1120,and Emerging US State and Federal Healthcare AI Obligations |
| |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in clinical and healthcare decision contexts subject to qualified human reviewer requirements under the US Joint Commission and Coalition for Health AI (CHAI) Responsible Use Guide (September 2025), California Senate Bill 1120 (SB 1120, effective January 1, 2025), New York Assembly Bill A9149 (pending), and related US state and federal healthcare AI accountability obligations. The profile -- designated CareGuard -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the qualified human reviewer documentation requirements, clinical decision traceability obligations, and AI governance evidence standards applicable to healthcare AI deployments. The profile addresses four clinical deployment categories: medical necessity determinations, clinical decision support, diagnostic AI assistance, and prior authorisation AI systems. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | AI Discovery and Retrieval Endpoint (AIDRE) |
| |
|
This document specifies the AI Discovery and Retrieval Endpoint (AIDRE), a protocol for publishing machine-oriented, canonical, and semantically retrievable content on the web. AIDRE defines a discovery document, collection metadata, retrieval interfaces, optional vector-native query support, and content representation rules for AI systems. AIDRE aims to reduce redundant crawling, parsing, tokenization, and embedding of the same origin content while improving freshness, provenance, and interoperability for AI systems. |
| | OMP Domain Profile: Automated Decision Systems Accountability in Employment Under California FEHC CRC Regulations,New York City Local Law 144,and Related ADS Accountability Obligations |
| |
| | draft-veridom-omp-employ-00.txt |
| | Date: |
05/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for automated decision systems (ADS) deployed in employment contexts subject to the California Civil Rights Council (CRC) Employment Regulations on Automated Decision Systems (effective October 1, 2025), New York City Local Law 144 (bias audit requirement for automated employment decision tools), the Illinois Artificial Intelligence Video Interview Act (AIVIA), and related US state and municipal ADS accountability obligations in employment. The profile -- designated WorkMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the record-retention, named accountability, bias audit evidence, and per- decision auditability requirements applicable to employment ADS deployments. The profile directly addresses the California CRC requirement to retain ADS inputs, outputs, decision criteria, and audit results for four years with named accountability for AI- assisted hiring and employment decisions. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). |
| | Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs |
| |
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. |
| |
|
| |
| | Currently Used Terminology in Global Routing Operations |
| |
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. |
| | Current Options for Securing Global Routing |
| |
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. |
| | The Preliminary Request Denied HTTP Status Code |
| |
|
This specification defines a HTTP status code to indicate that the server is denying a prefetch or preload request. |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. 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/tfpauly/privacy-proxy. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Using the Internet Key Exchange Protocol Version 2 (IKEv2) for PSP Key Management |
| |
|
This document specifies how the Internet Key Exchange Version 2 (IKEv2) protocol can be used for supplying keys for the PSP Security Protocol (PSP). |
| | Using LISP as a Network Substrate for AI Agent Communication |
| |
|
The emergence of distributed artificial intelligence (AI) systems, particularly those composed of autonomous agents operating across cloud, edge, and endpoint environments, introduces new networking requirements. These include location transparency, seamless mobility, multi-homing, and logical isolation at scale. This document explores how the Locator/ID Separation Protocol (LISP) can serve as a robust network substrate to meet these requirements. The document outlines use cases, design considerations, and minimal extensions to the existing LISP framework to support context-aware mapping and AI agent-centric communication. |
| | Parent-Centric Delegation Handling in DNS Resolvers |
| |
|
This document specifies an optional parent-centric behavioral model for DNS recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut and are never overwritten by child-side NS data. The parent-centric model eliminates the "two sources of truth" problem inherent in the current DNS delegation design, closes the Ghost Domain and Phoenix Domain attack vectors, provides deterministic behavior in the presence of parent/child NS mismatches, and enables resolvers to safely accept sibling (out-of-bailiwick) glue by scoping delegation information to individual zone cuts. It also provides the behavioral foundation required for deployment of the DELEG extensible delegation mechanism. This document updates [RFC1034] and [RFC1035]. |
| | TLS for Secure Element Recursive Authentication |
| |
|
This document defines a recursive authentication architecture based on the TLS 1.3 pre-shared key (PSK) mode. In this context, TLS servers, typically hosted within secure elements (TLS-SE), realize procedures that compute TLS 1.3 PSK-binder and Handshake Secret. These procedures allow a client to authenticate to downstream TLS servers without directly possessing the corresponding PSKs. Authentication capabilities can therefore be delegated across multiple TLS servers while maintaining protection of the underlying secrets. |
| | OMP Domain Profile: Legal AI Supervision Under ABA Model Rule 5.3 and California Senate Bill 574 |
| |
| | draft-veridom-omp-legal-00.txt |
| | Date: |
03/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for legal AI deployments subject to attorney supervision obligations under ABA Model Rule 5.3 Responsibilities Regarding Nonlawyer Assistance and California Senate Bill 574 (SB 574, effective January 1, 2026). These instruments impose principal accountability requirements on attorneys who use AI tools to assist with legal work product -- requiring attorneys to verify AI-generated material, ensure compliance with professional duties, and maintain evidence of supervision. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the attorney supervision obligations imposed by Rule 5.3 and SB 574, and defines the domain-specific Watchtower configurations, Named Accountable Officer assignments, and Audit Trace schema extensions applicable to legal AI deployments. The profile is designated the CiteGuard profile. The OMP core specification is defined in a separate Internet-Draft. |
| | OAuth 2.0 Agents Native Authorization via Structured Elicitation |
| |
|
This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification [FiPA], establishing a standard metadata format for FiPA authorization challenge responses. FiPA leaves the format for advertising available authenticators and their required inputs undefined, preventing interoperable implementation by AI Agents and other non- browser clients. This extension adds an elicitations array to the FiPA Authorization Challenge Response, providing a standard metadata format for authenticator challenges. Model Context Protocol (MCP) Elicitation [MCP-Elicitation] is the normative reference binding. This specification covers the just-in-time (JIT) authorization for AI Agents executing on behalf of users in Human-to-Agent (H2A) flows. |
| | SAIP: Signed Agent Identity Protocol |
| |
|
The modern web lacks a reliable mechanism for verifying the identity of HTTP user agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rise of automated agents. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP enables servers to distinguish between legitimate automated traffic and malicious actors. |
| | OMP Domain Profile: EU AI Act Article 12 Logging and Traceability Requirements for High-Risk AI System Operators |
| |
| | draft-veridom-omp-euaia-00.txt |
| | Date: |
03/04/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo, Festus Makanjuola |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI system operators subject to Article 12 of Regulation (EU) 2024/1689 (the EU AI Act). Article 12 requires that high-risk AI systems automatically generate tamper- resistant logs capable of ensuring traceability throughout the system's lifetime. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture (SHA-256, RFC 3161, institution signature) satisfy the Article 12 requirements, and defines the domain-specific Watchtower configurations and Audit Trace schema extensions applicable to EU high-risk AI deployments under Annex III of the Regulation. The core OMP specification is defined in a separate Internet-Draft (\"Operating Model Protocol (OMP): A Deterministic Decision-Enforcement Protocol with Externalized Proof-of-Integrity\"). |
| | PCEP Extension for Layer 2 (L2) Flow Specification |
| |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| |
|
| |
| | SNAC Router Flag in ICMPv6 Router Advertisement Messages |
| |
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-24.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-25.txt |
| | Date: |
02/04/2026 |
| | 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 Transport Network (TN) 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 TN slices using UDP source port number of the GTP-U bearer when the TN 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. |
| | Downgrade Prevention for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that prevents particular downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. This document updates RFC 7296. |
| | Post-Stack MPLS Network Action (MNA) Header Specification |
| |
| | draft-ietf-mpls-mna-ps-hdr-08.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Jie Dong, Jisu Bhattacharya |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) Header Specification for carrying Network Actions encodings and Ancillary Data after the MPLS label stack, based on the In-Stack MNA Specification defined in "MPLS Network Action (MNA) Sub-Stack Specification." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user- defined operations. This document follows the framework specified in RFC 9789. |
| | YANG module file name convention |
| |
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and draft-ietf-netmod-rfc8407bis. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths by combining path segments obtained through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists |
| |
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 which is compliant with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificate Management over CMS |
| |
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8756], the CNSA 1.0 guidance. |
| | A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators |
| |
|
This document codifies a consistent and reversible convention used in the threat intelligence and security communities for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It describes a safe obfuscation format that reduces the risk of accidental execution or activation when IOCs are displayed or transmitted. The recommended form brackets the URI scheme name (for example, [http]) so that the string is not syntactically a valid URI per generic URI parsers; legacy scheme-substitution tokens are defined for de-obfuscation interoperability. These conventions aim to improve interoperability among tools and feeds that exchange threat intelligence data. |
| | Deployment and Use of the Domain Name System(DNS) in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | The Rewind Subscription Filter |
| |
|
This document proposes a Media Over Quic Transport (MOQT) extension that enables a new Subscription Filter, so that a subscriber can request that a finite number of past groups be delivered with SUBSCRIBE semantics (multiple streams, potentially incomplete) rather than FETCH semantics (single stream, complete, head-of-line- blocking). Service of this request is best-effort by the publisher, and it intended to accelerate joining a track in some use cases. |
| | TLS-Session-Bound Access Tokens for OAuth 2.0 |
| |
|
This document defines a mechanism for binding OAuth 2.0 access tokens to a specific mutual TLS (mTLS) connection. The binding is achieved through a proof token that incorporates the TLS Exporter value [RFC5705] derived from the current connection and an access token hash, signed by the client's private key corresponding to its mTLS certificate. This mechanism prevents stolen bearer tokens from being replayed on a different TLS connection. The proof is constructed once per (token, connection) pair and reused across all requests on that connection, delivering session binding with no per-request signing overhead and no additional key management beyond what mTLS already provides. The mechanism is applicable to TLS 1.2, TLS 1.3, and QUIC transports. While applicable to any OAuth 2.0 access token presented over mTLS, this specification is primarily motivated by the Token Exchange protocol [RFC8693], where multi-hop delegation chains in autonomous, agent-driven architectures create elevated replay risk. |
| | A Layman's Guide to a Subset of ASN.1,BER,and DER |
| |
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The particular purpose of this note is to provide background material sufficient for understanding and implementing the RSA Data Security, Inc. Public Key Cryptography Standards (PKCS) family of standards. This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79. |
| | Open Mesh Protocol (OMP): A Multi-Radio Proximity Mesh Networking Architecture and Problem Statement |
| |
|
This document describes the Open Mesh Protocol (OMP), a proposed open standard for device-native proximity mesh networking spanning multiple radio technologies simultaneously. Existing proximity wireless mesh standards -- including Wi-Fi Aware (NAN), Bluetooth Mesh, and Thread -- each operate over a single radio technology and serve specific application domains. No existing open standard provides a unified multi-radio mesh routing protocol spanning BLE, WiFi Direct, and LoRa with per-device cryptographic identity independent of any central registry or carrier relationship. This document describes the OMP architecture, specific technical implementations, and the gap in the current standards landscape that OMP addresses. It is submitted as an Informational Internet-Draft to establish a public prior art record and to invite community discussion on whether a new working group or individual submission track is appropriate for this work. |
| | AAuth Protocol |
| |
|
This document defines the AAuth authorization protocol, in which agents obtain proof-of-possession tokens from auth servers to access resources on behalf of users and organizations. It specifies three token types (agent, resource, and auth), a unified token endpoint with deferred response support, and cross-domain federation between auth servers. It builds on the AAuth Headers specification ([I-D.hardt-aauth-headers]), which defines the AAuth-Requirement response header and HTTP Message Signatures profile. |
| | HTTP AAuth Headers |
| |
|
This document defines two HTTP response headers — AAuth-Requirement and AAuth-Error — and profiles HTTP Message Signatures ([RFC9421]) for request authentication, with keying material conveyed via the Signature-Key header ([I-D.hardt-httpbis-signature-key]). A server uses AAuth-Requirement to require pseudonymous or verified agent identity, to request user interaction, or to signal that approval is pending. AAuth-Error conveys structured error information. Both headers use extensible registries for their values. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS |
| |
|
This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf- mcast-addr-alloc-ps. |
| | Reference Interaction Models for Remote Attestation Procedures |
| |
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| | CCF Profile for COSE Receipts |
| |
|
This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proof specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. |
| | Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors |
| |
|
A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document proposes a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-mpls-01.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR-MPLS networks using the Simple Two- Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for SR-MPLS paths (including Segment Lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SR-MPLS paths. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-srv6-01.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement for SRv6 using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths. |
| |
|
| |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. |
| | OAuth Profile for Open Public Clients |
| |
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2 (see RFC7862). |
| | The Network File System Access Control List Protocol |
| |
|
This Informational document describes the NFS_ACL protocol. NFS_ACL is a legacy member of the Network File System family of protocols that NFS clients use to view and update Access Control Lists stored on an NFS version 2 or version 3 server. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
The current ACME protocol [RFC8555] requires applicants to submit a PKCS#10 Certificate Signing Request (CSR) during the finalization phase. The construction, ASN.1 encoding, and transmission of the CSR impose additional implementation burdens on both the client (especially resource-constrained devices) and the server. Moreover, the CSR cannot prevent a public key from being replaced by an intermediary at the protocol level. This document introduces the "pk-01" challenge extension based on the ACME protocol. Its core mechanism is as follows: the applicant declares the public key to be authenticated during the "newOrder" phase and completes the Proof of Possession (PoP) by signing with the private key during the challenge phase. Since the public key is declared when the order is created and verified during the challenge phase, there is no need to submit a CSR during the finalization phase; the ACME server can issue the certificate directly based on the verified public key, thereby eliminating the CSR at the protocol level. The "pk-01" challenge supports two verification modes via the pop_mode field: |
| | Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements |
| |
|
This document describes use cases and requirements for VESPER (Verifiable STI Presentation and Evidence for RTU), an extension to the Secure Telephone Identity Revisited (STIR) framework. VESPER defines a delegate certificate profile that binds telephone number authority, entity identity, and originating provider authorization into a single verifiable trust artifact, grounded in Right-to-Use (RTU) validation and recorded in a public transparency log. The document identifies the trust gaps that motivate this work and describes requirements for verifiable origination authorization. |
| | Hybrid Post-Quantum Password Authenticated Key Exchange |
| |
| | draft-vos-cfrg-pqpake-01.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Jelle Vos, Stanislaw Jarecki, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is the result of a KEM-based transformation from the hybrid symmetric PAKE protocol called CPaceOQUAKE that is also described in this document. This document recommends configurations for CPaceOQUAKE+. |
| | VESPER Out-of-Band OOB |
| |
|
This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework in environments where SIP signaling is unavailable or unsuitable. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within SIP-based VoIP networks. These PASSporTs are signed with delegate certificates that were authorized for issuance by corresponding authority tokens, which represent the trust and validation of telephone number control and related claim information. Transparency features ensure that these authorizations are publicly auditable and cryptographically provable, supporting a higher standard of trust. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to-end accountability. The OOB mechanism serves as an alternative delivery path for PASSporTs in cases where end-to-end in-band SIP delivery is not possible, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. |
| | Quantum Datagram Control Protocol (QDCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qdcp-01.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | Update to Recognize the IETF IPMC as the IETF Trust Successor |
| |
|
This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation. Discussion of this draft is on the ipr-wg@ietf.org mailing list. |
| | Use Cases for Authentication of Web Bots |
| |
|
This draft outlines use cases for authentication for bot clients on the Web, to help inform discussions regarding the scope and intent of the WebBotAuth Working Group. |
| | Ogg Stem Files |
| |
|
This document defines a multi-track profile of the Ogg container format for storing for storing stems for use by DJ applications while remaining backwards compatible with existing media players. |
| | EDNS options for filtering information |
| |
|
This memo documents EDNS options, EDNS Extended DNS Errors INFO-CODE values, and methods that can be used to return information about filtered, blocked, or censored DNS responses. It complements the information provided in EDNS Extended DNS Error options [RFC8914]. |
| | Additional Security Algorithms For Use With TCP-AO |
| |
|
RFC5926 specifies cryptographic algorithms for TCP-AO. It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC as KDFs. It also explains how to use HMAC-SHA-1-96 and AES-128-CMAC-96 as MAC algorithms. This document specifies several new KDFs and MAC algorithms for TCP- AO. The KDFs and MAC algorithms specified in this document use stronger cryptography. |
| | The Emerging Application of AI in IETF Specifications |
| |
|
Over recent years we have seen the emergence of Artificial Intelligence (AI) systems as tools that can contribute to the specification, implementation, and operation of Internet technologies. This document examines the potential for making increased use of Machine Learning (ML) in the scope of the IETF. |
| | Problem Statement for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents now act on behalf of people across communication, automation, and decision-making contexts. These agents increasingly initiate actions, delegate tasks, and interact with other agents without a clear, durable, or verifiable connection to the human who authorized them. Existing identity systems authenticate software, but they do not provide a model for human anchoring, scoped delegation, or provenance across agent ecosystems. This document describes the problem space for human-anchored agent identity. It outlines the gaps in current identity mechanisms, the risks created by uncontrolled replication and impersonation, and the need for a consistent architectural model that preserves human authority, supports explicit delegation, and maintains verifiable provenance across contexts. This document does not define a protocol. It defines the problem that an architectural model must address in order to support safe, accountable, and interoperable agent ecosystems. |
| | Architecture for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents increasingly act on behalf of people across communication, automation, and decision-making contexts. These agents initiate actions, delegate tasks, and interact with other agents without a consistent model for representing the human who authorized them, the scope of authority they possess, or the provenance of their actions across ecosystems. This document defines an architectural model for human-anchored agent identity. The model introduces a human identity root, explicit delegation semantics, and a provenance structure that enables ecosystems to determine whether an agent is legitimate, whether it is acting within its intended authority, and how its actions relate to a responsible human. This document does not define a protocol or wire format. It provides an architectural foundation that existing systems may bind to in order to support accountable, interoperable, and human-aligned agent ecosystems. |
| | Agentic Identity and Provenance over Avian Carriers (AIPAC) |
| |
|
This document specifies a method for establishing cryptographic identity and provenance attestation for agentic AI systems operating over Avian Carriers (AC). As large language models increasingly delegate sub-tasks to other models via pigeon, questions of authorship, intent, and hallucination propagation across feather- based transport layers demand urgent standardization. This document extends the delegation chain model and provenance structure of draft-beyer-agent-identity-architecture-00 to the specific constraints of feather-based transport layers, and extends RFC 1149, RFC 2549, and RFC 6214 to address agent identity. It is an April 1 publication. |
| | Domain-based Integrity Verification Enforcement (DIVE) Version 0.1 |
| |
|
Domain-based Integrity Verification Enforcement (DIVE) version 0.1 is an application-layer protocol that provides cryptographic integrity and authenticity verification of web resources by leveraging the Domain Name System Security Extensions (DNSSEC) as an independent verification channel. DIVE operates as an additional security layer above HTTP and HTTPS. Public keys and policy configuration are published as DNS TXT records protected by DNSSEC, while HTTP response headers carry per-resource cryptographic signatures. A client implementing DIVE verifies each covered resource against the corresponding DNS-published public key before accepting it. An attacker must therefore compromise both the DNS infrastructure and the origin server simultaneously in order to deliver a tampered resource to a DIVE-compliant client. This document defines the DNS record format, the HTTP header format, the client verification algorithm, the reporting mechanism, and the operational recommendations for the DIVE 0.1 protocol. |
| | Text Encoded Base 64 Numbers (Ten64) |
| |
|
Ten64 is a positional numeral system for representing numeric values with an alphabet of 64 characters (aka. radix/base 64). However, unlike most positional number systems, the characters are written in ascending (aka. big-endian, network-order) and NOT descending order. The main differences are the use of sextets (six bits) instead of octets (aka. bytes). Similar to hexadecimal, Ten64 can be used to create binary strings of arbitrary length. Ten64 can encode one or more Modern Western Numbers (aka. Arabic, Vedic), interpreting the characters respective composite big-endian binary as a one or more Modern Western Numbers. The motivation for Ten64 is to encode numbers in a compact and human- readable format similar to Base58. However, Ten64 is designed to be optimized for use with numbers commonly used in identifiers, such as DIDs, DOIDs, IANA OIDs, UUIDs, dates, time(stamp)s, points, and more. Unlike Base58, and more like hexadecimal Ten64 aligns the Modern Western Numerals with the respective big-ending binary (i.e.; 0 → 0, 1 → 1, 2 → 11, etc). Finally, Ten64 provides a disk-based number encoding system for huge numbers and number streams. |
| | vCon Extension for Morse Code Dialog Encoding |
| |
|
This document defines a vCon extension for representing Morse code conversations within the Virtualized Conversation (vCon) container format. Morse code remains an actively used communication medium among amateur radio operators, in historical preservation contexts, and in cultural works. The extension provides standardized encoding for Morse code dialog, including keying timing data, prosign representation, and the Farnsworth timing method. This document also addresses information-theoretic considerations of Morse code's variable-length encoding, its relationship to modern source coding theory, and the privacy implications of preserving historically significant Morse code conversations whose data subjects may be deceased. |
| | Monotonic Attestation Service (MAS) |
| |
|
This document defines the Monotonic Attestation Service (MAS), a protocol for issuing cryptographically attested, monotonically increasing sequence numbers within named namespaces. Each attestation includes a hash chain linking it to all prior entries in the namespace, providing verifiable proof of ordering and completeness. MAS is designed to complement RFC 3161 Trusted Timestamping: where RFC 3161 proves when an event occurred, MAS proves in what order and that the sequence is complete. |
| | UTF-8 Internet Protocol Addresses |
| |
|
This memo describes an alternate entry and display format for IPv6 addresses using UTF-8 instead of hextets. A mixed representation for traditional IPv6 address prefixes also is explored, along with means of transitioning between the two within an IPv6 address. Additionally, an address extension is proposed to accommodate the inevitable need for longer addresses. Finally, security implications of special UTF-8 glyphs are considered. |
| | Signed Email Authentication Layer (SEAL) |
| |
|
This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that is independent of the mutable RFC 5322 header block and message body. SEAL is designed to complement or replace DKIM and ARC by eliminating their dependency on mutable message components and by providing a canonical, tamper- evident identity layer that survives transit through intermediaries. |
| | Security Considerations for Intent-Based Requests in Agentic Systems |
| |
|
Intent-based requests enable users, applications, and agents to express goals and constraints without specifying step-by-step procedures. Such intents are commonly translated into executable directives and propagated across multiple entities (clients, agents, authorization components, orchestration functions, and execution endpoints). This multi-hop processing expands the attack surface for tampering, privilege escalation, constraint bypass, and intent drift. This document provides a solution-agnostic security analysis for intent-based requests across agentic systems. It introduces a reference model and scenarios to guide protocol and system design, and also presents threats and requirements. The document emphasizes constraint validation, invocation validation, multi-hop chain-of- custody, and policy-driven responses to drift, while remaining independent of any specific deployment domain. |
| | A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-15.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
|
A Segment Routing (SR) Policy Candidate Path can contain multiple Segment Lists, allowing for load-balancing and protection across diverse paths. However, current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. This document defines PCEP extensions to encode multiple Segment Lists within an SR Policy Candidate Path, enabling multipath capabilities such as weighted or equal-cost load-balancing across Segment Lists. The extensions are designed to be generic and reusable for future path types beyond SR Policy, and are applicable to both stateless and stateful PCEP. |
| | Adapting Constrained Devices for Post-Quantum Cryptography |
| |
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. |
| | QMux |
| |
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. |