| |
|
| |
| | The IPv6 VPN Service Destination Option |
| |
|
This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment. |
| | Segment Routing over IPv6 Argument Signaling for BGP Services |
| |
|
RFC9252 defines procedures and messages for BGP Overlay Services for Segment Routing over IPv6 (SRv6) including Layer 3 Virtual Private Network, Ethernet Virtual Private Network, and Global Internet Routing. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifiers advertisements for BGP Overlay Service routes associated with SRv6 Endpoint Behaviors that support arguments. |
| | CoAP Management Interface (CORECONF) |
| |
| | draft-ietf-core-comi-20.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. |
| | COSE Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. |
| | Extensible Delegation for DNS |
| |
| | draft-ietf-deleg-00.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
DNS Delegation (deleg) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, for delegation the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| | draft-ietf-dhc-rfc8415bis-10.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). |
| | YANG Data Model for BGP about RPKI |
| |
|
This document defines YANG data models for configuring and managing BGP information about Resource Public Key Infrastructure (RPKI). |
| | Fully-Specified Algorithms for JOSE and COSE |
| |
|
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers and deprecates those polymorphic algorithm identifiers, enabling applications to use only fully- specified algorithm identifiers. This specification updates RFC 7518, RFC 8037, and RFC 9053. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-01.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). |
| | Optional IS-IS Fragment Timestamping |
| |
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for the high-speed and high-throughput data transmission within completion time in High Performance Wide Area Network (HP-WAN). It particularly enhances the congestion control and facilitates the functionalities for the host to collaborate with the network to perform rate negotiation, such as QoS policy, admission control, traffic scheduling and so on. |
| | Getting Nameservers in the New Delegation Protocol |
| |
|
The DELEG Working Group has chosen a base protocol that describes how resolvers will be able to get a new DNS resource record to create a new process for DNS delegation. After a resolver gets this new type of record, it needs to know how to process the record in order to get a set of nameservers for a zone. This document lists many of the considerations for that process, including many open questions for the DELEG Working Group. More considerations and open questions might be added in later versions of this draft. Note that this draft is _not_ intended to become an RFC. It is being published so that the DELEG Working Group has a place to point its efforts about how resolvers get nameservers for a zone while it continues to work on choosing a base protocol. The work that results from this might be included in the base protocol specification, or in a new draft authored by some of the many people who have done earlier work in this area. |
| | Standard Communication with Network Elements (SCONE) Protocol |
| |
| | draft-thoji-scone-protocol-00.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Individual Submissions (none) |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. |
| | SR Policy Extensions for energy efficiency |
| |
|
[draft-liu-spring-sr-energy-efficiency-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document details the extensions to the BGP SR Policy and BGP-LS SR Policy to encapsulate the energy consumption information for each segment list of the SR Policy candidate paths, enabling its utilization in the route selection process. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-11.txt |
| | Date: |
06/05/2025 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. |
| | TCP ACK Rate Request Option |
| |
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. |
| |
|
| |
| | Meticulous Keyed ISAAC for BFD Optimized Authentication |
| |
|
This document describes a new BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the the "Up" state. |
| | Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. |
| | Structured Error Data for Filtered DNS |
| |
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| | Performance Measurement with Asymmetrical Traffic Using STAMP |
| |
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables control of the length and/or number of reflected packets during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further request. |
| | LISP Geo-Coordinates |
| |
|
This document describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates, which is compatible with the Global Positioning Satellite (GPS) encodings used by other routing protocols. This document updates RFC8060. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. |
| | YANG Data Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Plane |
| |
|
Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. Path Segment can be used in an SR over MPLS (SR-MPLS) data plane. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV and sub-TLV definitions for PSID. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-41.txt |
| | Date: |
05/05/2025 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Computing Aware Traffic Steering (CATS) with Generic Metric |
| |
|
Steering traffic for computing-related services considering computing resources and circumstances is discussed in CATS WG. Correspondingly, publishing services and updating computing conditions turns out to be a significant issue. It SHOULD be realized that multiple same common metrics are required from both network and service instances in order to evaluate overall performance and further achieve and fulfill appropriate traffic steering and scheduling. Therefore, an implementation for distributed CATS with generic metrics delivery and distribution based on BGP is proposed and discussed in this draft. |
| | Applying Attachmet Circuit and Traffic Engineering YANG Data Model to Edge AI Use Case |
| |
|
This document explores how existing IETF YANG data models, specifically the Attachment Circuit (AC)-as-a-Service (ACaaS) and Traffic Engineering (TE) topology data models, can be applied to support a use case involving dynamic AI model placement at Edge Cloud sites. The use case involves selecting optimal Edge locations for real-time AI inference based on end-to-end network performance between street-level cameras and Edge Cloud compute nodes. By mapping the use case across multiple network segments and applying relevant YANG data models to retrieve and request specific services objectives such as bandwidth, latency, and reliability, this document serves as a practical exercise to evaluate model applicability and identify gaps, if any. |
| | Framework,Use Cases and Requirements for AI Agent Protocols |
| |
|
AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. |
| | Reservation of f000::/4 for Structured Internal-Use IPv6 Addressing |
| |
|
This document proposes the reservation of the IPv6 address block f000::/4 for structured internal-use networking. This allocation extends the concepts of Unique Local Addresses (ULAs) as defined in RFC 4193, acknowledging the growing demand for a larger, more hierarchically organised, and clearly non-internet-routable address space for internal networks. The reservation of f000::/4 would prevent future conflicts with public allocations and provide operational clarity to large-scale, privacy-focused, or non-public infrastructures. |
| | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. |
| | Task Binding and In-Band Provisioning for DAP |
| |
|
An extension for the Distributed Aggregation Protocol (DAP) is specified that cryptographically binds the parameters of a task to the task's execution. In particular, when a client includes this extension with its report, the servers will only aggregate the report if all parties agree on the task parameters. This document also specifies an optional mechanism for in-band task provisioning that builds on the report extension. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-03.txt |
| | Date: |
05/05/2025 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| | TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key |
| |
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media |
| |
|
This document describes RTCP messages and RTP header extensions to enable partial access and support viewport- and region-of-interest- dependent delivery of visual volumetric media such as visual volumetric video-based coding (V3C). Partial access refers to the ability to access retrieve or deliver only a subset of the media content. The RTCP messages and RTP header extensions described in this document are useful for XR services which transport coded visual volumetric content, such as point clouds. |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. |
| | TLS Extension for DANE Client Identity |
| |
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. |
| | Computerate Specification |
| |
|
This document specifies computerate specifications, which are the combination of a formal and an informal specification such as parts of the informal specification are generated from the formal specification. |
| | A Formalization of Symbolic Expressions |
| |
|
The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. |
| | Constrained GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the UDP-based Constrained GeneRic Autonomic Signaling Protocol (cGRASP), which is designed to be a constrained and lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. cGRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource- constrained devices dominate. Given the established ecosystem of CoAP and aiming to promote cGRASP adoption in IoT, this document also focuses on the cGRASP transition from UDP to a CoAP-based framework, i.e., CoAP-based cGRASP. Furthermore, this document also discusses the potential way to adapt the cGRASP to work on the network without IP connectivity. |
| | RSVP Cryptographic Authentication with HMAC-SHA2 |
| |
|
This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. |
| |
|
| |
| | RTP Payload Format for sub-codestream latency JPEG 2000 streaming |
| |
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given codestream can be emitted before the entire codestream is available. |
| | An Attribute for Statement of Possession of a Private Key |
| |
|
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. |
| | Remote Procedure Call over QUIC Version 1 |
| |
|
This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. |
| | Template-Driven HTTP Request Proxying |
| |
|
HTTP request proxying behaviors have long been part of the core HTTP specification. However, the core request proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative proxy service configuration for HTTP requests. The proxy service is identified by a URI Template, similarly to "connect-tcp" and "connect-udp". |
| | JSContact Extensions |
| |
|
Extensions to the JSContact data model for contact card data are defined to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card. |
| | DNS Zone Version (ZONEVERSION) Extended |
| |
|
The DNS Zone Version (ZONEVERSION) extended is a way to get information about the version of a DNS in the backend. For example when a DNSSEC signer for a zone generates a new SOA serial, because it has created new RRSIG records, the original data has not changed, but this is not visible to anyone looking at the zone. This document will make it possible show the zone information which is the base of the presented data. |
| | Federated Authentication of Entities |
| |
| | draft-halen-fedae-00.txt |
| | Date: |
02/05/2025 |
| | Authors: |
Jakob Schlyter, Stefan Halen |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Federated Authentication of Entities (FedAE) framework, enabling secure machine-to-machine communication within a federation. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedAE ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. |
| | Network File System version 4.2 COPY Operation Implementation Experience |
| |
|
This document describes the authors' experience implementing the NFSv4.2 COPY operation, as described in [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 access and modify Access Control Lists stored on an NFS version 2 or version 3 server. |
| | OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents |
| |
|
This specification defines an extension to the OAuth 2.0 Authorization Framework [RFC6749] to enable AI agents to obtain delegated access tokens to act on behalf of users. It introduces a new authorization request parameter, requested_agent, and defines a grant type, urn:ietf:params:oauth:grant-type:agent- authorization_code, specifically designed to facilitate explicit user consent for an agent's actions and enable the agent to exchange an authorization code for a delegated access token using its own authentication credentials (an agent token). The extension ensures secure delegation, explicit user consent captured at the authorization server, and enhanced auditability through specific token claims that document the delegation path from the user to the agent acting via a client application. |
| | Updates to SIPREC correcting Metadata Media Type |
| |
|
The SIP-based Media Recording (SIPREC) protocol is defined by both Session Initiation Protocol (SIP) Recording Metadata (RFC 7865) and Session Recording Protocol (RFC 7866). Unfortunately, both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFCs registered the new media type. This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and registers the new media type. |
| |
|
| |
| | Update to the IANA CoAP Content-Formats Registration Procedures |
| |
|
This document updates RFC7252 regarding the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifier 64999 for use in documentation. |
| | Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. |
| | Certificate Management over CMS (CMC) |
| |
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFCs 5273 and 6402. |
| | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFCs 5274 and 6402. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments "ietf-system-capabilities" YANG module defined in [RFC9196]. The module provides transport protocol, transport encoding, and transport encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | Agreements To Fix Forwarding |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements. |
| | Distribution of Source Address Validation State in BGP |
| |
|
Source Address Validation (SAV) is a technique that can be used to mitigate source address spoofing. draft-huang-savnet-sav-table codifies the concept of source address validation on a per-incoming interface basis, the validation mode, and the traffic handling policy as a "SAV Table". This document defines a mechanism for distributing logical SAV Tables in BGP. This mechanism is addresses inter-domain SAV use cases. These SAV Tables may be used to implement appropriate device-specific validation for source addresses. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptographic algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. |
| | Using 802.1AB (LLDP) for IETF LSVR neighbor discovery and configuration |
| |
|
IEEE Std 802.1AB, known as the Link Layer Discovery Protocol (LLDP), can be applied to LSVR neighbor discovery and configuration. This can be achieved by using a nearest router group address as the LLDP Scope MAC Address to target LSVR interfaces while advertising a set of LSVR-specific LLDP TLVs. These LSVR-specific TLVs are defined using LLDP Organizationally Specific TLVs, as specified by LLDP for use by individual organizations to allow them to define their own Type-Length-Value (TLV) objects for exchange over the LLDP protocol. The IETF Organizationally Specific TLVs for LSVR can be encoded using the IETF IANA OUI (RFC 7042). This document provides an overview of applying LLDP to LSVR neighbor discovery and configuration and specifies the IETF Organizationally Specific TLVs that support link discovery for LSVR routers. In addition, a brief discussion of the use of IEEE Connectivity Fault Management (CFM) as specified in IEEE Std 802.1Q-2022 cl 18-22 for link liveliness is included. |
| | Information and Data Models for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-07.txt |
| | Date: |
01/05/2025 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines an information model and a corresponding YANG data model for packet discard reporting. The information model provides an implementation-independent framework for classifying packet loss to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this framework for network elements. |