| |
|
| |
| | Controller-based BGP Multicast Signaling |
| |
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. |
| | YANG Data Models for requesting Path Computation in WDM Optical Networks |
| |
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| | BBR Congestion Control |
| |
| | draft-ietf-ccwg-bbr-02.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Neal Cardwell, Ian Swett, Joseph Beshay |
| | Working Group: |
Congestion Control Working Group (ccwg) |
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. |
| | A publish-subscribe architecture for the Constrained Application Protocol (CoAP) |
| |
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. |
| | Reliable and Available Wireless Architecture |
| |
|
Reliable and Available Wireless (RAW) extends the reliability and availability of DetNet to networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet service sublayer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. |
| | BGP Classful Transport Planes |
| |
| | draft-ietf-idr-bgp-ct-39.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Kaliraj Vairavakkalai, Natrajan Venkataraman |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") procedures and follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") NLRI encoding is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. |
| | Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features that can provide secure operation. This document describes the integrity protection of IOAM-Data-Fields. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for network inventory. The scope of this base model is set to be application- and technology-agnostic. However, the data model is designed with appropriate provisions to ease future augmentations with application- and technology-specific details. |
| | SASL Remember Me |
| |
|
Introduces a SASL mechanism that allows the application to stay logged in and re-login without user interaction, after completing a time-consuming SASL login mechanism that involves the user. |
| | More Instant Messaging Interoperability (MIMI) message content |
| |
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| | Network Digital Twin: Concepts and Reference Architecture |
| |
|
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concepts of Network Digital Twin, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | Layer-3 Accessible EVPN Services |
| |
|
This draft describes layer-3 accessible EVPN service interfaces, which aim is to connect the layer 2 customers to one EVPN backbone, via the layer 3 network, and keep the traffic isolation among different layer 2 customers. It proposes to extend the VxLAN packet format to transfer the customer's Virtual Network Identifier(VNI) information, and also the related control plane extension. |
| | Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) |
| |
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and draft-ietf-cbor-cddl-more-control (RFC-to-be 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. |
| | MoQ relays for Support of High-Throughput Low-Latency Traffic in 5G |
| |
|
This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MoQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MoQ that is equivalent to what is possible for RTP. |
| | SR Policy Group |
| |
| | draft-cheng-spring-sr-policy-group-07.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Weiqiang Cheng, Jiang Wenying, Changwang Lin, Yuanxiang Qiu, Yawei Zhang, Ran Chen, Yanrong Liang |
| | Working Group: |
Individual Submissions (none) |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR policy and SR Policy Group to provide best practice cases for operators |
| | BGP Flow-Spec Traffic Compress Action |
| |
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. This document specifies a new traffic filtering action to support compressing traffic. |
| | Philatelist,YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases |
| |
|
Timestamped telemetry data is collected en masse today. Mature tools are typically used, but the data is often collected in an ad hoc manner. While the dashboard graphs look great, the resulting data is often of questionable quality, not well defined, and hard to compare with seemingly similar data from other organizations. This document proposes a standard, extensible, cross domain framework for collecting and aggregating timestamped telemetry data in a way that combines YANG, metadata and Time Series Databases to produce more transparent, dependable and comparable results. This framework is implemented in the Network Controller layer, but is rooted in data that is collected from all kinds of Network Elements and related systems. |
| | TLS Flag - Request mTLS |
| |
|
Normally in TLS there is no way for the client to signal to the server that it has been configured with a certificate suitable for mTLS. This document defines a TLS Flag [I-D.ietf-tls-tlsflags] that enables clients to provide this hint. |
| | Application of Explicit Measurement Techniques for QUIC Troubleshooting |
| |
| | draft-mdt-quic-explicit-measurements-02.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Alexandre Ferrieux, Igor Lubashev, Giuseppe Fioccola, Lars Ihlar, Fabio Bulgarella, Mauro Cociglio, Isabelle Hamchaoui, Massimo Nilo |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). |
| | Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
| |
|
The document [I-D.draft-mhkk-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. |
| | End-to-End Secure Objects for Media over QUIC Transport |
| |
|
This document describes an end-to-end authenticated encryption scheme for application objects intended to be delivered over Media over QUIC Transport (MOQT). We reuse the SFrame scheme for authenticated encryption of media objects, while suppressing data that would be redundant between SFrame and MOQT, for an efficient on-the-wire representation. |
| | SPICE GLUE: GLobal Unique Enterprise (GLUE) Identifiers |
| |
|
This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace. |
| | Upper limit values for DNS |
| |
|
There are parameters in the DNS protocol that do not have clear upper limit values. If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks, and several attack methods have been proposed. This draft proposes reasonable upper limit values for DNS protocols. |
| | IGP Reverse Prefix Metric |
| |
|
This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. |
| | RTP payload format for APV |
| |
| | draft-lim-rtp-apv-01.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Individual Submissions (none) |
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APC) codec. |
| | The Challenges and Requirements for Routing in Computing Cluster network |
| |
|
This document explores the characteristics of computing cluster network and analyzes the challenges of employing the traditional distributed or centralized routing mechanisms in it. In order to achieve the enhanced scalability, improved resilience and optimized performance simultaneously, hybrid routing is briefly examined as a potential way to combine the advantages of distributed and centralized mechanisms. The document further shows the possible future work. |
| | A YANG Data Model for In Situ Operations,Administration,and Maintenance (IOAM) Integrity Protected Options |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. I-D.ietf-ippm- ioam-data-integrity defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the configuration of these Integirty Protected Options. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network or Intent-based Networking, and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. |
| | Applicability of TVR YANG Data Models |
| |
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include resource preservation networks, operating efficiency networks and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. |
| | Evidence Transformations |
| |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo, concise evidence, and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation and follow CoRIM defined appraisal procedures. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information which contained QUIC Header, QUIC Frame and Stream that traffic is being forwarded with. |
| | Eligibility Concept in Segment Routing Policies |
| |
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. |
| | Privacy Pass with Token Binding Extension |
| |
|
This document provides a token binding extension for the Privacy Pass protocol. This extension allows a Client to cryptographically bind a Privacy Pass token to its own generated one-time public key during the issuance flow, without exposing the public key to the Issuer. Later, when spending the token during the redemption flow, the Client must use the corresponding private key to generate a binding proof that the Origin needs to additionally verify except the token itself, where the proof generation can optionally support channel binding. This proof constrains the legitimate presenter of the token to be only the Client who holds the private key and further constrains the legitimate usage of the token to be only the Client's specific channel when channel binding is used in the proof generation, and thus can prevent token export and replay attacks. In addition, the token binding extension does not introduce additional cryptographic primitives, and only uses the primitives currently utilized in the issuance protocol to generate the one-time public-private keypair as well as generate and verify the binding proof. |
| | A Generic Framework for Building Dynamic Decentralized Systems (GFDS) |
| |
| | draft-jesus-gfds-00.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Diogo Jesus, Joao Leitao |
| | Working Group: |
Individual Submissions (none) |
|
Building and managing highly dynamic and heterogeneous decentralized systems can prove to be quite challenging due to the great complexity and scale of such environments. This document specifies a Generic Framework for Building Dynamic Decentralized Systems (GFDS), which composes a reference architecture and execution model for developing and managing these systems, while providing high-level abstractions to users. |
| | RFC Editor Model |
| |
|
RFC 9280 specifies version 3 of the RFC Editor Model. Since its publication, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/ (https://datatracker.ietf.org/edwg/rswg/documents/). There is a repository for this draft at https://github.com/ paulehoffman/9280-updates (https://github.com/ paulehoffman/9280-updates). |
| | Service Binding Mapping for Service Levels |
| |
|
This document defines a new SvcParamKey for use in Service Binding (SVCB) and HTTPS DNS resource records which enables authoritative DNS servers to indicate that a service should be used by clients having specific service levels or use types, such as "interactive", "background" or "realtime". By providing this information, clients can make informed decisions about which service endpoints to use based on specific applications needs at that time of making connections. |
| | Use SVCB with DNS Service Discovery |
| |
|
DNS Service Discovery (DNS-SD) relies on a sequence of steps to enable the discovery and connection to local network services. The use of Service Binding (SVCB) resource records during the service discovery process enables service instances to advertise properties such as Application-Layer Protocol Negotiation (ALPN) identifiers and other endpoint configuration options. This document describes the use of SVCB / HTTPS RRs in the DNS Service Discovery process as an additional step to allow clients to connect to service instances optimally. |
| | QUIC Acknowledgment Frequency |
| |
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-12.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines a conceptual message wrapper (CMW) format - an encapsulation method applicable to any RATS conceptual message, such as Evidence, Attestation Results, Endorsements, and Reference Values. It also describes a collection type that aggregates one or more CMWs into a single message. In addition, this document specifies a corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, and an X.509 extension. These mechanisms enable the embedding of enveloped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. Moreover, a Media Type and a CoAP Content-Format are defined for transporting CMWs over HTTP, MIME, CoAP, and other Internet protocols. |
| | Circuit Style Segment Routing Policies |
| |
| | draft-ietf-spring-cs-sr-policy-05.txt |
| | Date: |
28/02/2025 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. SR Policies satisfying these requirements are called "circuit-style" SR Policies (CS-SR Policies). |
| | OCSP Usage for Secure Telephone Identity Certificates |
| |
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. |
| |
|
| |
| | Transmission of IPv6 Packets over Short-Range Optical Wireless Communications |
| |
| | draft-ietf-6lo-owc-03.txt |
| | Date: |
27/02/2025 |
| | Authors: |
Younghwan Choi, Cheol-min Kim, Carles Gomez |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) communications. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | Limits on Sending and Processing IPv6 Extension Headers |
| |
|
This document defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. Limits are pragmatic to facilitate interoperability amongst hosts and routers, thereby increasing the deployability of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. |
| | Delegation Revalidation by DNS Resolvers |
| |
|
This document recommends improved DNS resolver behavior with respect to the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the TTL of either the parent or child NS RRset, whichever comes first. |
| | Compact Denial of Existence in DNSSEC |
| |
|
This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFC 4034 and 4035. |
| | Alternate Marking Deployment Framework |
| |
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. |
| | IS-IS YANG Model Augmentations for Additional Features - Version 1 |
| |
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, IS-IS Application-Specific Link Attributes as defined in RFC 9479, IS-IS Flexible Algorithm as defined in RFC 9350, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. |
| | Realization of Composite IETF Network Slices |
| |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. |
| | Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on ISO and Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms is ISO standardization and are mandatory for some scenario in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | EVPN Route Types and Procedures for EVN6 |
| |
|
EVN6 is a mechanism designed to carry Ethernet virtual networks, providing Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 directly places the Ethernet frames in the payload of IPv6 packet, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. |
| | Integrated Sensing and Communications (ISAC) use case for GREEN |
| |
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents a use case related to ISAC, aiming to facilitate discussions within the GREEN Working Group on the potential benefits, challenges, and requirements. The use case follows a structured template that we propose for all GREEN use cases, ensuring consistency and comparability across different scenarios. |
| | Integrated Sensing and Communications (ISAC) use case for CATS |
| |
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. This integration holds great potential for applications in areas such as autonomous systems, smart cities, and industrial automation, where precise sensing and low-latency communication are critical. This document presents a use case related to ISAC, aiming to facilitate discussions within the CATS Working Group on the potential challenges, and requirements. The aim for this document is to facilitate discussion in the CATS WG for potential consideration of the use case. |
| | Deferred Key Binding for OAuth |
| |
|
Sometimes you want to get a token that's tied to a public key but you can't prove possession of that public key. That's when you need to trust me, bruh. |
| | Requirements for Monitoring RPKI-Related Processes on Routers Using BMP |
| |
|
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers, including data retrieval from RPKI caches, policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize RPKI monitoring within BMP, addressing scalability and interoperability limitations in existing implementations. |
| | QUIC Multimedia Performance |
| |
|
The QUIC multimedia performance protocol (QPERFM) updates the QUIC performance protocol (QPERF). QPERF provides a simple, general- purpose protocol for testing the performance characteristics of a QUIC implementation. QPERFM updates that protocol to simulate the traffic of multimedia application and measure performance in a multi- media oriented way. 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-huitema-moq-qperfm/. |
| | Non-work Conserving Stateless Core Fair Queuing |
| |
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [draft-ietf-detnet-dataplane-taxonomy-02]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded between ET and FT in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously compute ET and FT based on metadata received via packet headers. This mechanism is called non-work-preserving stateless fair queuing, which guarantees both E2E latency upper and lower bounds. |
| | Adapting HSMs for Post-Quantum Cryptography |
| |
|
Hardware Security Modules (HSMs) play a critical role in securing cryptographic operations, including the adoption of Post-Quantum Cryptography (PQC). This document examines the use of seed-based key generation in HSMs, which reduces storage requirements but increases computational overhead for key derivation. It explores trade-offs between storage efficiency and performance, addressing challenges in ephemeral key handling and optimization strategies for PQC signature algorithms. It also discusses PQC impacts to HSM firmware updates and backup. |
| | xml2rfc svg limitations |
| |
|
This is a draft explores limits of SVG artwork in xml2rfc. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-04.txt |
| | Date: |
27/02/2025 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. |
| | 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. |
| | Static Context Header Compression and Fragmentation over networks prone to disruptions |
| |
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension |
| |
| | draft-ietf-acme-ari-08.txt |
| | Date: |
26/02/2025 |
| | Authors: |
Aaron Gable |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies how an ACME server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods. |
| | BFD Stability |
| |
| | draft-ietf-bfd-stability-17.txt |
| | Date: |
26/02/2025 |
| | Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD packet loss. |
| | BIER BFD |
| |
| | draft-ietf-bier-bfd-08.txt |
| | Date: |
26/02/2025 |
| | Authors: |
Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. |
| | Flexible Hybrid PQ MLS Combiner |
| |
|
This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ security that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e. an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. |
| | NETCONF Transport Port Numbers |
| |
|
This document releases NETCONF-related port number IANA assignments that were made for inappropriate transport protocols or for Historic NETCONF-related protocols. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Configuration Working Group mailing list (netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/netconf-port-numbers. |
| | SRH TLV Processing Programming |
| |
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
| |
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. |
| | DetNet multidomain extensions |
| |
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. |
| | A Multiplane Architecture Proposal for the Quantum Internet |
| |
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. |
| | Enhanced Encapsulating Security Payload (EESP) |
| |
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add Flow IDs (e.g., for CPU pinning and QoS support), and a crypt-offset to allow for exposing inner flow information for middlebox use. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. |
| | Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
As well as the Internet Control Message Protocol for IPv4 (ICMPv4), the Internet Control Message Protocol for IPv6 (ICMPv6) is significant for network diagnostics and error reporting. However, like ICMPv4, ICMPv6 is also vulnerable to off-path forgery, making it difficult for the receiver to verify the legitimacy of a received ICMPv6 error message, particularly when the message contains stateless protocol data (e.g., the message includes a UDP/ICMPv6 packet). Consequently, adversaries on the Internet can forge ICMPv6 error messages carrying stateless protocol data, leading the receiver to erroneously accept the forged message and respond to it. This document proposes enhancement to ICMPv6 by introducing a challenge- confirm mechanism that leverages random numbers embedded in the IPv6 Extension Headers. The enhancement aims to strengthen the authentication of ICMPv6 error messages, thereby mitigating the risks associated with forged messages and improving the overall robustness of the protocol. |
| | Knowledge Graph Construction from Network Data Sources |
| |
|
This document discusses the mechanisms that support the management and creation of knowledge graphs from data sources specific to the network management domain. The document provides background on core aspects such as ontology development, identifies methodologies and standards, and shares guidelines for integrating network data sources. |
| | Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol (ICMP) plays a crucial role in network diagnostics and error reporting. However, it is a challenge to verify the legitimacy of a received ICMP error message, particularly when the ICMP error message is embedded with stateless protocol data. As a result, adversaries can forge ICMP error messages, leading to potential exploitation and off-path attacks. This document proposes a novel method to enhance ICMP authentication by introducing a challenge-confirm mechanism. This mechanism embeds random numbers in the IP options field to strengthen the authentication of ICMP error messages. By doing so, it mitigates the risks associated with forged messages, improves the overall robustness of the protocol, and enhances network security. The proposed solution includes details on the challenge-confirm mechanism, random number generation and management, and integration with IP options. Additionally, it discusses security and deployment considerations to ensure its practical implementation. |
| | Support for BMP RIB Purge Notification |
| |
|
This document describes a mechanism to notify a BMP collector of the need to purge the state associated with a RIB view of a specific peer. This is useful, for example, when the BMP sender decides to stop exporting a specific RIB view after providing an initial export. The BMP collector can use the per-peer Purge message to take appropriate action to remove the stale state and avoid holding on to irrelevant network data. |
| | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
|
RFC 6514 describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. This document updates and obsoletes RFC 6514. The original authors of RFC 6514 are listed at the end of this document. |
| | Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks |
| |
|
This document describes the approach of gradually deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also discusses the challenges and potential solutions. |
| | Active OAM for use in Geneve |
| |
| | draft-ietf-nvo3-geneve-oam-16.txt |
| | Date: |
26/02/2025 |
| | Authors: |
Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol designed to encapsulate network packets for transport across underlying physical networks. This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks. It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol to support network operators in maintaining reliable and efficient virtualized network environments. |
| | Path Computation Element Protocol (PCEP) Extension for Color |
| |
| | draft-ietf-pce-pcep-color-12.txt |
| | Date: |
26/02/2025 |
| | Authors: |
Balaji Rajagopalan, Vishnu Beeram, Shaofu Peng, Mike Koldychev, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute. |
| | 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. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-02.txt |
| | Date: |
26/02/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. |
| |
|
| |
| | Entering IPv6 Zone Identifiers in User Interfaces |
| |
|
This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874 and updates RFC 4007, RFC 7622 and RFC 8089. Discussion Venue This note is to be removed before publishing as an RFC. Discussion of this document takes place on the 6MAN mailing list (ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/ (https://mailarchive.ietf.org/arch/browse/ipv6/). |
| | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
| |
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic techniques to achive hybrid post- quantum/traditional (PQ/T) key encapsulation mechanisms (KEMs) from post-quantum and traditional component algorithms that meet specified security properties. It then uses those generic techniques to construct several concrete instances of hybrid KEMs. |
| | Methods for Detection and Mitigation of BGP Route Leaks |
| |
|
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. |
| | The Idempotency-Key HTTP Header Field |
| |
|
The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. |
| | HTTP Link Hints |
| |
|
This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. |
| | The HTTP QUERY Method |
| |
|
This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. |
| | Hybrid Two-Step Performance Measurement Method |
| |
|
The development and advancements in network operation automation have brought new measurement methodology requirements. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. That task can be solved using on-path telemetry, also called hybrid measurement. An on-path telemetry method allows the collection of essential information that reflects the operational state and network performance experienced by the packet. This document introduces a method complementary to on-path telemetry that causes the generation of telemetry information. This method, referred to as Hybrid Two-Step (HTS), separates the act of measuring and/or calculating the performance metric from collecting and transporting network state. The HTS packet traverses the same set of nodes and links as the trigger packet, thus simplifying the correlation of informational elements originating on nodes traversed by the trigger packet. |
| | Key Transparency Architecture |
| |
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply KT to a number of common applications. |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-02.txt |
| | Date: |
25/02/2025 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | 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. |
| | Extending ICMPv6 for SRv6-related Information Validation |
| |
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. |
| | An SR-TE based Solution For Computing-Aware Traffic Steering |
| |
|
Computing-aware traffic steering (CATS) is a traffic engineering approach [I-D.ietf-teas-rfc3272bis] that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. Various relevant metrics may be used to enforce such computing-aware traffic steering policies.It is critical to meet different types of computing-aware traffic steering requirements without disrupting the existing network architecture. In this context, this document proposes a computing-aware traffic steering solution based on the SR- TE infrastructure of the current traffic engineering technology to reduce device resource consumption and investment and meet the requirements for computing-aware traffic steering of network devices. |
| | CDNI Metadata Expression Language |
| |
|
This document specifies the syntax and provides usage examples for an expression language to be used within Streaming Video Technology Alliance (SVTA)/Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| | CDNI Processing Stages Metadata |
| |
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| | Semantic Definition Format (SDF) modeling for Digital Twin |
| |
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its interactions. An SDF is a format to describe Things and their associated interactions, and to represent the various kinds of information that is exchanged for these interactions. Therefore, the SDF format can be used to define the behavior of things, i.e. physical objects, and related data and interaction models in a digital twin that contain objects as components. |
| | Post-Quantum Cryptography Recommendations for TLS-based Applications |
| |
|
Post-quantum cryptography presents new challenges for applications, end users, and system administrators. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and key supporting protocols such as DNS. |
| | IPv6 Address Assignment for SRv6 |
| |
|
This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios. |
| | Flow Aggregation for Enhanced DetNet |
| |
|
This document describes the objectives and requirements of flow aggregation in scaling networks. It proposes a scheme by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet, and suggests the flow identification of aggregated-class be used to indicate the required treatment and forwarding behaviors in scaling networks. Toward the end, the draft discuss how the novel flow aggregation scheme could be applied to realize the flow aggregation in a 5GS logical DetNet node participating in enhanced DetNet. |
| | Operations,Administration and Maintenance (OAM) for Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-oam-fw-02.txt |
| | Date: |
25/02/2025 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an OAM framework for Computing-Aware Traffic Steering (CATS). The proposed OAM framework enables the fault and the performance management of end-to-end connections from clients to networks and finally to computing instances. In the following sections, the major components of the framework, the functionalities, and the deployment considerations are elaborated in detail. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-muti-dp-solution-02.txt |
| | Date: |
25/02/2025 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios. |
| | CDNI Source Access Control Metadata |
| |
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| | CDNI Delivery Metadata |
| |
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior for downstream CDN (dCDN) node selection, and request routing modes of traffic delegation. |
| | CDNI Private Features Metadata |
| |
|
This specification defines a mechanism for downstream content delivery networks (dCDNs) to define private extensions to the metadata model that are mutually agreed upon between participating upstream content delivery networks (uCDNs) and dCDNs. |
| | On-Path Telemetry for Active Performance Measurements |
| |
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-flow-lb-01.txt |
| | Date: |
25/02/2025 |
| | Authors: |
FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, Bin Tan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a flow-level load balancing solution for CATS, and is designed to effectively manage CS-ID traffic by addressing issues like frequent control plane operations and uneven use of computing resources. The approach entails concurrently identifying multiple next-hop choices, factoring in both network pathways and service instances. Traffic is then distributed among these service instances using flow-based load balancing, which relies on the five- tuple characteristics of packets. |
| | PCE Communication Protocol (PCEP) extensions for updating Open Message content |
| |
|
This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to update information previously exchanged during PCEP session establishment via the Open message. |
| | RPKI Repository Problem Statement and Analysis |
| |
|
With the widespread deployment of Route Origin Authorization (ROA) and Route Origin Validation (ROV), Resource Public Key Infrastructure (RPKI) is vital for securing inter-domain routing. RPKI uses cryptographic certificates to verify the authenticity and authorization of IP address and AS number allocations and the certificates are stored in the RPKI Repository. This document conducts the data-driven analysis of the RPKI Repository, including a survey of worldwide AS administrators and a measurement and analysis of the existing RPKI Repository. This document finds that the current RPKI Repository architecture is sensitive to failures and lacks of scalability. An attack or downtime of any repository Publication Point (PP) will prevent RPs from obtaining complete RPKI object views. Furthermore, since the current RPKI Repository is not tamper-resistant, RPKI authorities can easily manipulate RPKI objects without consent from subordinate INR holders. This document also defines the key requirements for a reliable, scalable, and secure RPKI Repository. |
| | Security considerations for IPv6 Packets over Short-Range Optical Wireless Communications |
| |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes security considerations for short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | Problem Statement for High Performance Wide Area Networks |
| |
|
High Performance Wide Area Network (HP-WAN) is designed for many applications such as scientific research, academia, education and other data-intensive applications which demand high-speed data transmission over WANs, and it needs to provide efficient transmission services within a completion time. This document outlines the problems for HP-WANs. |
| | IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP) |
| |
|
This document specfies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in draft-klassert-ipsecme-eesp, provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. |
| | Secure DNS RR Update for ACME DNS Based Challenges |
| |
|
This document outlines how ACME DNS based challenges can be performed via DNS dynamic updates. 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-li-acme-dns-update/. Discussion of this document takes place on the WG Working Group mailing list (mailto:acme@ietf.org), which is archived at https://datatracker.ietf.org/wg/acme/about/. Subscribe at https://www.ietf.org/mailman/listinfo/acme/. |
| | Trustworthy Routing Discovery |
| |
|
End users with high security and privacy requirements expect their data to be transmitted only through trusted devices to mitigate the risk of data leakage. Therefore, the development of trustworthy routing mechanisms is anticipated to be a key trend in the future evolution of the internet. This specification describes a network architecture that supports trustworthy routing and a scheme for carrying trustworthy routing information (TRI) using the BGP and BGPsec protocols. |
| | the service model of NASR |
| |
|
This document describes the service model of Network Attestation for Secure foRwarding (NASR). It lists security capabilities and characteristics of connectivity services that operators can offer and clients can choose from. |
| | Improvement of Congestion Control Methods Based on Bandwidth Measurement |
| |
|
This document discusses how the Congestion Control algorithm integrates and utilizes the bandwidth, rate recommendations, and constraints etc. provided by bandwith measurement to achieve better congestion control.This document discusses how the Congestion Control algorithm. |
| | Sigma Protocols |
| |
|
This document describes Sigma protocols, a secure, general-purpose non-interactive zero-knowledge proof of knowledge. Concretely, the scheme allows proving knowledge of a witness, without revealing any information about the undisclosed messages or the signature itself, while at the same time, guarantying soundness of the overall protocols. |
| | Implicit ECH Configuration for TLS 1.3 |
| |
|
This document updates the TLS Encrypted ClientHello (ECH) specification [ECH-DRAFT] to support an implicit mode in ECH signaled by a new implicit_ech extension in ECHConfigContents. Clients that detect this extension override certain base ECH rules: * They MAY choose any outer SNI instead of public_name. * They MAY choose any value for the config_id without an application profile or being externally configured. * They MAY use another value than ECHConfig.contents.public_name in the "server_name" extension (rather than they SHOULD use it) Client-facing servers that include implicit_ech in the ECHConfig MUST accommodate flexible config_id usage as defined in Section 10.4. of [ECH-DRAFT]. This approach enables the removal of stable identifiers (fixed config ID and known public_name) that on-path adversaries can use to fingerprint a connection. This improves upon the "Do Not Stick Out" design goal from Section 10.10.4 of [ECH-DRAFT] by allowing clients to choose unpredictable identifiers on the wire in the scenario where the set of ECH configurations the client encounters is small and therefore popular public_name or config_id values "stick out". Note that this increases CPU usage in multi-key deployments because client-facing servers must perform uniform trial decryption to handle arbitrary config_id values. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/grittygrease/draft-sullivan-tls-implicit-ech. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-ietf-regext-epp-quic-00.txt |
| | Date: |
25/02/2025 |
| | Authors: |
Jiankang Yao, Hongtao Li, Man Zhang, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-14.txt |
| | Date: |
25/02/2025 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture |
| | TLS Trust Anchor Identifiers |
| |
|
This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency. |
| | Prefer use of RFC8781 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis |
| |
|
On networks providing IPv4-IPv6 translation (NAT64, RFC7915), hosts and other endpoints might need to know the IPv6 prefix used for translation (the NAT64 prefix). While RFC7050 defined a DNS64-based prefix discovery mechanism, more robust methods have since emerged. This document provides updated guidelines for NAT64 prefix discovery, deprecating the RFC7050 approach in favor of modern alternatives (e.g., RFC8781) except where those are unavailable. |
| | The WebTransport Protocol Framework |
| |
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension |
| |
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". |
| | BIER Fast ReRoute |
| |
| | draft-ietf-bier-frr-07.txt |
| | Date: |
24/02/2025 |
| | Authors: |
Huaimo Chen, Mike McBride, Steffen Lindner, Michael Menth, Aijun Wang, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. The proposed solution enhances the resiliency of BIER by providing a method to quickly reroute traffic in the event of a link or node failure, thereby minimizing packet loss and service disruption. The document details the procedures for detecting failures and selecting backup paths within the BIER domain, ensuring that multicast traffic continues to reach its intended destinations without requiring per-flow state or additional signaling. This FRR mechanism is designed to integrate seamlessly with existing BIER operations, offering a robust solution for improving network reliability. |
| | Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| | BMP v4: TLV Support for BGP Monitoring Prtoocol (BMP) Route Monitoring and Peer Down Messages |
| |
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types. |
| | A Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines three YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers. Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server |
| | One Administrative Domain using BGP |
| |
| | draft-uttaro-idr-bgp-oad-06.txt |
| | Date: |
24/02/2025 |
| | Authors: |
Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). |
| | Security and Privacy Implications of 3GPP AI/ML Services for 6G |
| |
|
This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) services. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. |
| | Common BMP Route-Monitoring Messages for Routes Unchanged by Policy |
| |
|
A route unmodified by the inbound policy on a monitored router is included both in Pre-Policy Adj-RIB-In as well as Post-Policy Adj- RIB-In Route-Monitoring messages when both the Pre-Policy and Post- Policy Route-Monitoring modes are enabled. Similarly, a route unmodified by the outbound policy is included in Pre-Policy Adj-RIB- Out as well as Post-Policy Adj-RIB-Out Route-Monitoring messages. This document defines methods to avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out. |
| | Gap Analysis,Problem Statement,and Requirements in AI Networks |
| |
|
This document provides the gap analysis of AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | A OSF Framework for Artificial Intelligence (AI) Network |
| |
|
This document describes a framework for Artificial Intelligence (AI) network, Particularly, the document identifies a set of AI network components, describes their interactions, and exemplifies the workflow of the control and data planes. |
| | PAKE Usage in TLS 1.3 |
| |
|
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as an authentication and key establishment in TLS 1.3, and that supports PAKE algorithms negotiation. |
| | Post-Handshake Authentication via PAKE for TLS 1.3 |
| |
|
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as a post-handshake authentication for TLS 1.3, and that supports PAKE algorithms negotiation and optional channel binding. |
| | VCON for MIMI Messages |
| |
|
This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (MIMI) content format. |
| | DNS Update with JSON |
| |
|
It is common for service providers such as certificate authorities and social media providers to want users to update the users' zones to prove that they control those zones, or to add other features. Currently, service providers tell users to do this using human language describing the resource record type and data values to enter into the zone. This document describes a text format, called "DNS update with JSON" or "DUJ", for such a service provider to give to a user, with the expectation that the user would copy and paste the text to their DNS operator to update the user's zone. DNS operators who know how to handle DUJ strings will make the update process easier and more predictable for their users. |
| | YANG Data Model for Energy Measurements in Streaming Devices |
| |
|
This document defines a YANG data model for representing energy measurements from streaming-capable devices. The model supports both instantaneous power readings and correlated streaming metrics needed to analyze energy efficiency in streaming applications. |
| | Procedures for Handling Liaison Statements to and from the IETF |
| |
|
This document describes the procedures for generating and handling liaison statements between the IETF and other SDOs, so that the IETF can effectively collaborate with other organizations in the international standards community. |
| | IAB Processes for Management of IETF Liaison Relationships |
| |
|
This document discusses the procedures used by the IAB to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers, and the expectations of the IAB in establishing liaison relationships. |
| | Caller ID Verification In Session Initiation Protocol |
| |
| | draft-hao-civ-00.txt |
| | Date: |
24/02/2025 |
| | Authors: |
Feng Hao, Basil Thomas, Steve Smith, Muhammad Azad |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support the Caller ID Verification (CIV) protocol proposed by Wang et al. in ACM Transactions on Privacy and Security (2023). CIV authenticates the caller ID of an incoming call through a challenge-and-response process. When receiving a call with a claimed phone number, the called party holds the call and sends an INVITE request to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller should receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi- Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new options tag, "civ", in the Supported header field. This tag indicates that the calling party supports CIV. Second, it adds a special value "civ-veri-call" for the Purpose parameter of the Call-Info header field. This value indicates that the purpose of the INVITE request is to verify the caller ID based on CIV. Compared with STIR/SHAKEN, CIV authenticates the caller ID (not the carrier), does not require trusted certificate authorities and works with both IP and non-IP networks. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-00.txt |
| | Date: |
24/02/2025 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest |
| |
| | draft-ietf-suit-manifest-33.txt |
| | Date: |
24/02/2025 |
| | Authors: |
Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, Oyvind Ronningstad |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. |
| |
|
| |
| | BIER Prefix Redistribute |
| |
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| | TCP-AO Protection for BGP Monitoring Protocol (BMP) |
| |
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. 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/hmntsharma/draft-hmntsharma-bmp-tcp-ao. |
| | BGP Colored Prefix Routing (CPR) for SRv6 based Services |
| |
| | draft-ietf-idr-cpr-08.txt |
| | Date: |
23/02/2025 |
| | Authors: |
Haibo Wang, Jie Dong, Ketan Talaulikar, hantao, Ran Chen |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored prefixes. This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. The existing IPv6 Address Family and Color Extended Community are reused for the advertisement of IPv6 Colored prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-Autonomous System (AS) networks which belong to the same trusted domain. |
| | Multicast YANG Data Model |
| |
|
This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter |
| |
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter during path computation. |
| | CDDL models for some existing RFCs |
| |
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc5661bis respecification effort for NFv4.1. It describes the structure and function of Access Control Lists within all existing minor versions of NFSv4. It describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. [Consensus Needed (Item #117a)]: Because of the failure of previous specifications to provide a satisfactory approach to either of the two ACL models for which support was originally intended, this document clarifies the status of draft POSIX ACLs, with the expectation that support for these might be provided via a later extension. In addition, this document will include some small protocol extensions to correct protocol defects, as provided for in RFC8178. [Consensus Needed (Item #117a)]: In this document, the relationship among the multiple ACL models supported has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now-withdrawn draft POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality within the NFSv4 ACL model and the full draft POSIX ACL model are considered as OPTIONAL extensions to that core, with the latter not yet present in NFsv4.1. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Unmasked BIER Mode |
| |
|
The document introduces a new mode of interpretation of the bitmask field in the BIER encoding, called unmasked BIER, that solves the problem of BIER originator targeting receivers across many different sets and hence, in worst case, degrading into ingress replication. |
| | ICMP Extension Header Length Field |
| |
|
The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | IETF Meeting Network Recommendations |
| |
|
IETF participants need a highly reliable and responsive network, with sufficient bandwidth to avoid congestion, that enables work to be conducted without interruption or network limitation during an IETF meeting. Such a network enables in-person network attendees to get their work done. It also enables remote participants to have a good experience as well, via remote participation in working group meetings. This document makes suggestions about how to reduce complexity, reduce cost, and increase reliability of the IETF meeting network, which may be helpful in community discussion. |
| | Compact DNSSEC |
| |
|
This document describes about a compact DNSSEC scheme for resource- limited second-level domain (SLD), which is focused on NS RR. |
| | Authenticated subdomain whitelist (ASDWL) for second-level domain (SLD) |
| |
|
This document describes about an authenticated subdomain whitelist (ASDWL) scheme to mitigate the random subdomain attacks on second- level domain (SLD). |
| | Extended Key Update for QUIC |
| |
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. |
| | Service Programming with Segment Routing |
| |
| | draft-ietf-spring-sr-service-programming-11.txt |
| | Date: |
23/02/2025 |
| | Authors: |
Francois Clad, Xiaohu Xu, Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma, Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. |
| |
|
| |
| | KangarooTwelve and TurboSHAKE |
| |
|
This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. |
| | Definition For New BGP Monitoring Protocol (BMP) Statistics Types |
| |
|
RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines new statistics type to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs). |
| | The Hashed Token SASL Mechanism |
| |
| | draft-ietf-kitten-sasl-ht-00.txt |
| | Date: |
21/02/2025 |
| | Authors: |
Florian Schmaus, Christoph Egger |
| | Working Group: |
Common Authentication Technology Next Generation (kitten) |
|
This document specifies the family of Hashed Token SASL mechanisms which enable a proof-of-possession-based authentication scheme and are meant to be used to quickly re-authenticate of a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round- trip property. The SASL mechanism specified herein further provides hash agility, mutual authentication and support for channel binding. |
| | IGP Unreachable Prefix Announcement |
| |
|
In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. |
| | Circuit Style Segment Routing Policies with Optimized SID List Depth |
| |
|
Service providers require delivery of circuit-style transport services in a segment routing based IP network. This document introduces a solution that supports circuit style segment routing policies that allows usage of optimized SID lists (i.e. SID List that may contain non-contiguous node SIDs as instructions) and describes mechanisms that would allow such encoding to still honor all the requirements of the circuit style policies notably traffic engineering and bandwidth requirements. |
| | EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission |
| |
| | draft-xls-intarea-evn6-03.txt |
| | Date: |
21/02/2025 |
| | Authors: |
Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| | DNS Filtering Details for Applications |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism that enable applications to convey the details of some filtering incidents to their users. 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/mnot/public-resolver-errors. |
| | QUIC network awareness Acknowledgements |
| |
|
This document defines a quic ACK frame format for notifying network status information. |
| | Registry scoped members for RPSL set objects |
| |
|
This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing SMTP related registries need to be restructured and existing entries need to be updated. This document describes these tasks. |
| | Lightweight Authentication Methods for IP Header |
| |
|
This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. |
| | Critical-CH for Client Hint Reliability |
| |
|
This document defines the Critical-CH HTTP response header to allow HTTP servers to reliably specify their Client Hint preferences. 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/Tanych/http-client-hint-reliability. |
| | Client Hint Reliability ACCEPT_CH Frame |
| |
|
This document defines the ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably specify their Client Hint preferences. It aims to improve the performance to deliver Client Hint. 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/Tanych/http-client-hint-reliability. |
| | JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
|
This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. |
| | PIM Join/Prune Attributes for LISP Environments using Underlay Multicast |
| |
|
This document specifies an update to the PIM Receiver RLOC Join/Prune attribute that supports the construction of multicast distribution trees where the source and receivers are located in different Locator/ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root Ingress Tunnel Router (ITR). This document updates RFC 8059. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-17.txt |
| | Date: |
21/02/2025 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| |
|
| |
| | Implementation Guidance for the PKCS #1 RSA Cryptography Specification |
| |
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. |
| | BGP Color-Aware Routing (CAR) |
| |
|
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. |
| | Segment Routing Segment Types Extensions for BGP SR Policy |
| |
|
This document specifies the signaling of additional Segment Routing Segment Types for signaling of Segment Routing (SR) Policies in BGP using SR Policy Subsequent Address Family Identifier. |
| | 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]. |
| | Transaction ID Mechanism for NETCONF |
| |
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. |
| | Testing async submission |
| |
|
This draft is submitted only to test the async api submission endpoint |
| | Supplement of BGP-LS Distribution for SR Policies and State |
| |
|
This document supplements additional information of the segment list in the BGP-LS advertisement for SR Policy state information. Two new flags are introduced in SR Segment List TLV of BGP-LS SR Policy Candidate Path NLRI. |
| | The Secondary Label and its applications |
| |
|
This draft utilizes the concept of a secondary label to solve few cases in L3VPN Deployments.In BGP VPN networks, BGP speakers associate a local MPLS label when the next-hop is reset and advertise that label to other peers. The receiving peer installs this "received" label in the forwarding and forwards traffic to the sending router using this label. In some deployments, there arises need where a different label is required to be sent. We illustrate with two use-cases. This draft presents a method where this label is encoded in a newly defined attribute that is advertised with the BGP updates targeting these specified use-cases |
| | An Analysis of ASPA-based AS_PATH Verification |
| |
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. |
| | OAM Requirements for Enhanced DetNet OAM |
| |
|
This document describes the specific requirements of the Operations, Administration, and Maintenance (OAM) for Enhanced DetNet, and analyzes the gaps with the existing OAM methods. It describes related OAM solutions considerations as well. |
| | BGP Extension for SRv6 Policy Segment List optimization |
| |
|
In some use cases, an SRv6 policy's segment list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This document specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. This optimization can improve the forwarding efficiency of data packets when End SID and Service SID are present. |
| | BGP SR Policy Extensions for Administrative Flags |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | High Performance Wide Area Network (HPWAN) Use Cases and Requirements -- From Public Operator's View |
| |
|
Bulk data transfer is a long-lived service over the past twenty years. High Performance Wide Area Networks (HP-WANs) are the backbone of global network infrastructure, enabling the seamless transfer of vast amounts of data and supporting advanced scientific collaborations worldwide. Many of the state-of-the-art dedicated networks have been mentioned in [I-D.kcrh-hpwan-state-of-art]. For non-dedicated networks like public operator's network, the case is different in terms of QoS policies, security policies, etc. This document presents use cases and requirements of HPWAN from public operator's view. |
| | Use of Variable-Length Output Preudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of variable-length output Preudo- 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 for the cases when variable-length output Preudo-Random Functions are used in IKEv2 and its extensions. |
| | Advertisement of SR Policy Administative Flags using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | IPv6 Checksum Option |
| |
|
This document specifies a Checksum Option for IPv6. This is a Destination Option that allows a checksum to be computed over a variable number of bytes in the packet. The option allows the ICMPv6 checksum to be optional, and the UDPv6 checksum to be generally optional. |
| | Date and Time on the Internet: Durations |
| |
|
This document specifies a syntax for representing time durations; the syntax is a subset of that specified by ISO 8601. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
| | draft-ietf-opsawg-ipfix-alt-mark-02.txt |
| | Date: |
20/02/2025 |
| | Authors: |
Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Massimo Nilo |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | Datagram PLPMTUD for UDP Options |
| |
|
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required. |
| |
|
| |
| | EAP-based Authentication Service for CoAP |
| |
| | draft-ietf-ace-wg-coap-eap-15.txt |
| | Date: |
19/02/2025 |
| | Authors: |
Rafael Marin-Lopez, Dan Garcia-Carrillo |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. |
| | Extensions to OSPF for Advertising Prefix Administrative Tags |
| |
|
It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. |
| | Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. |
| | IGP Flexible Algorithms Reverse Affinity Constraint |
| |
|
IGP protocols historically computed the best paths over the network solely based on the IGP metric assigned to the links. An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. Flex-Algorithm provides mechanisms to include or exclude links during the Flex-Algorithm path calculation. These allow the operator to influence the IGP best path selection. This document extends IGP Flex-Algorithm with additional constraints for inclusion or exclusion of links in the path based on Admin Groups associated with the reverse direction of the SPF path computation. |
| | The Messaging Layer Security (MLS) Extensions |
| |
|
The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. |
| | Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP) |
| |
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint Label Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint policies with SR over MPLS data plane. Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 address from the Dummy IPv6 range TBA2/64 (Section 7.1) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. |
| | A YANG Data Model for Network Incident Management |
| |
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and root cause analysis. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Galois Counter Mode with Strong Secure Tags (GCM-SST) |
| |
|
This document defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm. GCM-SST can be used with any keystream generator, not just 128-bit block ciphers. The main differences from GCM are the use of an additional subkey H_2, the derivation of fresh subkeys H and H_2 for each nonce, and the replacement of the GHASH function with the POLYVAL function from AES-GCM-SIV. This enables truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, which are significant security improvements over GCM. GCM-SST is designed for security protocols with replay protection and addresses the strong industry demand for fast encryption with minimal overhead and high security. This document registers several instances of GCM-SST using Advanced Encryption Standard (AES) and Rijndael-256. |
| | Using BMP over QUIC connection |
| |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. |
| | QUIC Profile for Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. In this context, typical QUIC stacks default transport parameters for terrestrial Internet are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case and guidance to QUIC stack developers to properly expose the required transport parameters in their API. |
| | Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
| |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| | Forward and Reverse HTTP/3 over WebTransport |
| |
|
HTTP/3 was initially specified only for use with the QUIC version 1 transport protocol. This specification defines how to use HTTP/3 over a WebTransport session, which can be implemented using any WebTransport protocol. This enables operation of HTTP/3 when UDP based transport is not available, as well as server-initiated HTTP/3 requests. |
| | Standardized Query Name for DNS Resolver Reachability Probes |
| |
|
This specification standardizes DNS names that should be used for checking connectivity to a DNS server. 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-sst-dnsop-probe-name/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/probe-name. |
| | Anomalous Packets Handling for DetNet |
| |
|
In deterministic networking (DetNet), there may be resource conflicts at the flow aggregation nodes, resulting in network anomalies. The existing mechanisms for handling anomalous packets in the data plane are crude, such as discarding or processing them as BE flows, so the network performance may be worse than applying traditional QoS. Therefore, in order to handle the anomalous traffic, the data plane should implement an enhanced handling mechanism. This document proposes an anomalous packet handling solution for anomalous traffic in DetNet. This solution includes two policies: the packet squeezing policy and the packet degrading policy, which can be applied flexibly to a variety of queuing mechanisms, thereby ensuring that network traffic for deterministic services is preferentially scheduled in anomalous situations. |
| | NTP Over PTP |
| |
|
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) which encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers which can timestamp only PTP messages and enables delay corrections in PTP transparent clocks. |
| | PCEP extensions for P2MP SR Policy |
| |
| | draft-ietf-pce-sr-p2mp-policy-11.txt |
| | Date: |
19/02/2025 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| | Working Group: |
Path Computation Element (pce) |
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaf nodes. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. Segment Routing (SR) technology leverages the source routing and tunneling paradigms. Each path is specified as a set of "segments" encoded in the header of each packet as a list of Segment Identifiers (SIDs). This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in the SRv6 (SR in IPv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID allocation and distribution. |
| |
|
| |
| | Service Registration Protocol for DNS-Based Service Discovery |
| |
| | draft-ietf-dnssd-srp-27.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Ted Lemon, Stuart Cheshire |
| | Working Group: |
Extensions for Scalable DNS Service Discovery (dnssd) |
|
The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. |
| | DTNMA Application Resource Identifier (ARI) |
| |
| | draft-ietf-dtn-ari-04.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Edward Birrane, Emery Annis, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. |
| | DTNMA Application Management Model (AMM) and Data Models |
| |
| | draft-ietf-dtn-amm-03.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a data model that captures the information necessary to asynchronously manage applications within the Delay- Tolerant Networking Management Architecture (DTNMA). This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements. |
| | DTNMA Application Data Model (ADM) YANG Syntax |
| |
| | draft-ietf-dtn-adm-yang-03.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. |
| | DTNMA Asynchronous Management Protocol (AMP) |
| |
| | draft-ietf-dtn-amp-01.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Edward Birrane, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport mapping for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management of resource constrained devices and over challenged networks. |
| | Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) |
| |
|
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535 identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | Extensible Delegation for DNS |
| |
| | draft-wesplaap-deleg-02.txt |
| | Date: |
18/02/2025 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | Track Switching in Media over QUIC Transport |
| |
|
This document defines a solution for switching tracks in media. More particularly, the solution provides a seamless switching that ensures there is no overlapping or gap between the download and/or transmission of two tracks when they are alternatives to each other. |
| | DNS to Web3 Wallet Mapping |
| |
|
This document proposes a implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security. |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines Post-Quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| | DNS Account Handles,A Whitepaper |
| |
|
A proposal for use of DNS names to support universal account identifiers 'handles' is described. Once registered, a handle may be used for authentication to any network service, to initiate communication with the holder or as the basis for IoT device management. This document is a whitepaper proposing the general approach. A strawman prototype supporting single account Web login across multiple sites, onboarding of IoT devices and end to end secure messaging, file-drop, voice and video and has been built using existing and proposed IETF work. |
| | Dynamic Overlay Load Balancing |
| |
|
This document specifies a mechanism for an overlay service ingress PE to dynamically load-balance traffic to Multi-Homing PEs based on near real-time access link information advertised by those PEs. |
| | Synchronized Video-on-Demand (VoD) Viewing with Media over QUIC Transport |
| |
|
This draft presents an approach for synchronized video-on-demand (VoD) viewing with Media over QUIC Transport (MOQT). It extends the current MOQT protocol to enable synchronized VoD functionality. This approach adapts MOQ’s push-content architecture to include interactive features such as pause, resume and seek. |
| | In Situ Operations,Administration,and Maintenance (IOAM) Active Measurement for Multi-path |
| |
|
Active measurements are typically used to collect the information of a specific path. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which promotes the information collection and topology restoration of a multi-path topology. It can help the operators to know the performance of network comprehensively and efficiently. |
| | A Profile for Forwarding Commitments (FCs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Forwarding Commitments (FCs) objects used in Resource Public Key Infrastructure (RPKI). An FC is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an FC's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. |
| | BGP AS_PATH Verification Based on Forwarding Commitment (FC) Objects |
| |
|
The Forwarding Commitment (FC) is an RPKI object that attests to the complete routing intents description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an FC-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that FC can help address and provides operational considerations associated with FC deployment. |
| | Roughtime |
| |
|
This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. |
| | Multi-segment SD-WAN via Cloud DCs |
| |
|
This document describes a method for SD-WAN Customer Premises Equipment (CPEs) to use GENEVE encapsulation (RFC8926) to transport IPsec-encrypted packets across a Cloud Backbone without requiring decryption at Cloud Gateways (GWs). In this approach, SD-WAN CPEs encapsulate IPsec-encrypted payloads within GENEVE headers and forward them to their nearest Cloud GWs. These Cloud GWs then steer the encrypted traffic through the Cloud Backbone while preserving its confidentiality, ensuring seamless transport to the destination Cloud GWs. The egress Cloud GWs subsequently deliver the original IPsec- encrypted payloads to the receiving CPEs. This mechanism enables the Cloud Backbone to interconnect multiple SD-WAN segments efficiently, eliminating the need for Cloud GWs to decrypt and re-encrypt payloads, thus enhancing the performance. |
| |
|
| |
| | The AEGIS Family of Authenticated Encryption Algorithms |
| |
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. 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/cfrg/draft-irtf-cfrg-aegis-aead. |
| | An EDNS(0) Option to Negotiate Leases on DNS Updates |
| |
|
This document describes an EDNS(0) option that can be used between DNS Update Requesters and authoritative DNS servers to include a lifetime (lease duration) in a DNS Update or DNS Update Response, allowing a server to garbage collect stale Resource Records that have been added by DNS Updates if they are not renewed. |
| | BGP UPDATE for SD-WAN Edge Discovery |
| |
|
The document describes the BGP mechanisms for SD-WAN edge node property discovery. These mechanisms include a new tunnel type and subTLVs for the BGP Tunnel-Encapsulation Attribute (RFC9012) and set of NLRI (network layer reachability information) for Software-Defined Wide-Area Network (SD-WAN) underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. |
| | Registration of further IMAP/JMAP keywords and mailbox attribute names |
| |
|
This document defines a number of keywords that have been in use by Fastmail and Apple respectively for some time. It defines their intended use. Additionally some mailbox names with special meaning have been in use by Fastmail, and this document defines their intended use. This document registers all of these names with IANA to avoid name collisions. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 12 of this protocol. |
| | Approaches on Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | Flag-based MPLS Network Actions (MNA) for On-Path Telemetry |
| |
|
This document describes the support of two flag-based variants of on- path Telemetry techniques, Postcard-Based On-Path Telemetry (PBT) and Alternate Marking (AM), as MPLS Network Actions (MNA)for OAM in MPLS networks. The scheme only uses a few bits in the MNA header opcode dedicated for the flag-based actions. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | Usage specification of the otpauth URI format for TOTP and HOTP token generators |
| |
|
This document describes a foundational schema for the otpauth URI, utilized by TOTP (and/or HOTP) based authenticators. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | Asset Schema Architecture for Asset Exchange |
| |
|
A management architecture for asset schemas and profiles is needed to enable entities in the tokenized assets ecosystem to instantiate tokens within one or more asset networks. An asset network may be constrained to support only a select class or type of token to be present in the network. In the SATP protocol, the receiving gateway at the destination network is assumed in its preparatory stages to evaluate the transfer request of a tokenized asset from the sending gateway at the origin network. In order to evaluate the proposed transfer, the receiving gateway must have access to the asset definition schema upon which the token was based in the origin network. The current document discusses the management architecture for the asset definition schema and the schema-profiles derived from the definition schema. |
| | Asset Profiles for Asset Exchange |
| |
|
A definition of asset schema and profiles is needed to provide a semantic definition of tokenized assets. The Asset schema is an abstract construct at the root hierarchy of more specific "asset profiles". Asset profiles describe the structure (type) of assets that are specific to a given domain or industry. An asset instance that is instantiated in a specific network and is exchanged via the SATP protocol has an instance-class relationship (in an ontological sense) with a given profile. Asset profiles are essential to the SATP protocol as they define the semantics of asset instances to be transferred. Gateways may negotiate asset transfers based on the nature and abilities of the assets as defined according to their profile. The current document discusses the definition of the asset schema and profile. |
| | SATP Setup Stage |
| |
|
SATP Core defines an unidirectional transfer of assets in three stages, namely the Transfer Initiation stage (Stage-1), the Lock- Assertion stage (Stage-2) and the Commitment Establishment stage (Stage-3). This document defines the Setup Phase, often called "Stage-0", prior to the execution of SATP Core. During Setup, the two Gateways that would participate in the asset transfer are bound together via a "transfer context". The transfer context conveys information regarding the assets to be exchanged. Gateway can perform any kind of negotiation based on that transfer context, before entering into SATP Core. |
| | IS-IS Extension for Big TLV |
| |
|
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a solution to IS-IS extension for encoding the TLV whose value is bigger than 255 octets. |
| | Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | Intra-domain Source Address Validation (SAV) Solution Based on BM-SPF |
| |
|
This draft proposes a new intra-domain Source Address Validation (SAV) solution. This solution leverages the Bidirectional Metric- based Shortest Path First (BM-SPF) mechanism to avoid the complexity introduced by asymmetric routing for source address validation. It allows intra-domain routers to generate directly the SAV rule from the router's FIB table, based on the reality that the source and destination interface will be same if the IGP domain is symmetric assured. |
| | 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. |
| | The Transport Layer Security (TLS) Protocol Version 1.3 |
| |
|
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. |
| |
|
| |
| | YANG Data Model for Automatic Multicast Tunneling |
| |
| | draft-ietf-mboned-amt-yang-03.txt |
| | Date: |
15/02/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Xuesong Geng, Vinod Nagaraj |
| | Working Group: |
MBONE Deployment (mboned) |
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. |
| | OSPF Adjacency Suppression |
| |
|
This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. |
| | IGP Prefix Independent Convergence |
| |
|
In many cases, a large number of routes can be reached by multiple next hops. When a link fails, route calculation needs to be performed and a new reachable path needs to be calculated. If all routes are re-calculated and refreshed, the calculation time increases linearly as the number of routes increases, resulting in a long time for route convergence. This document describes an architecture where the number of prefixes is independent. This architecture allows routes to be recalculated when paths change, regardless of the number of IGP routes. |
| | PCEP Extensions to Support Signaling Candidate Path Threshold Constraints of SR Policy |
| |
|
This document defines the extensions of PCEP to signal the threshold and metric constraint parameters of candidate paths for SR Policy to support flexible path selection. |
| | BIER Loop Avoidance using Segment Routing |
| |
| | draft-liu-bier-uloop-05.txt |
| | Date: |
15/02/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Yuanxiang Qiu |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a mechanism leveraging SR-MPLS/SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. |
| | Multicast Source Discovery Protocol (MSDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and the SendHoldTimer_Expires event in the MSDP protocol. The implementation of SendHoldTimer helps to address the situation where the local system detects that the remote system has not processed MSDP messages but has not terminated the MSDP session. According to this document, when the SendHoldTimer expires, the local system should close the MSDP session connection, rather than relying on the remote system to initiate the session closure. This document updates RFC3618. |
| | Label Distribution Protocol (LDP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires event in the LDP protocol. The implementation of SendHoldTimer helps address situations where the local system detects that the remote system has not processed LDP messages but has not terminated the LDP session. The document specifies that when the SendHoldTimer expires, the local system should close the LDP session connection, rather than solely relying on the remote system for session termination. This document updates RFC5036. |
| | Path Computation Element (PCE) Communication Protocol (PCEP) Send Hold Timer |
| |
|
This document defines the SendHoldTimer and SendHoldTimer_Expires events in the PCEP protocol. The implementation of SendHoldTimer helps address situations where a local system detects that a remote system has not terminated the PCEP session despite not processing PCEP messages. As per this document, when the SendHoldTimer expires, the local system should close the PCEP connection rather than solely relying on the remote system to terminate the session. This document provides updates to RFC5440. |
| | Intra-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Signaling SAVNET Capability Using IGP |
| |
|
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. |
| |
|
| |
| | LEDBAT++: Congestion Control for Background Traffic |
| |
|
This memo describes LEDBAT++, a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. LEDBAT++ has been implemented as a TCP congestion control algorithm in the Windows operating system. LEDBAT++ has been deployed in production at scale on a variety of networks and been experimentally verified to achieve the original stated goals of LEDBAT. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). |
| | IGP Flexible Algorithms: Bandwidth,Delay,Metrics and Constraints |
| |
|
Many networks configure the IGP link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms [RFC9350]provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. |
| | Prefix Flag Extension for OSPFv2 and OSPFv3 |
| |
|
Each OSPF prefix can be advertised with an 8-bit field to indicate specific properties of that prefix. However, all the OSPFv3 Prefix Options bits have already been assigned and only a few bits remain unassigned in the flags field of the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient prefix options bits by defining variable-length Prefix Attribute Flags Sub-TLV for OSPF. |
| | Carrying NRP related Information in MPLS Packets |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Multiple NRPs can be created by network operator to meet the diverse requirements of enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used as the NRP Selector to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the NRP Selector ID and related information in MPLS packets. The procedure for processing the NRP Selector ID and related information is also specified. |
| | BGP Extensions for the Mobile User Plane (MUP) SAFI |
| |
| | draft-mpmz-bess-mup-safi-05.txt |
| | Date: |
13/02/2025 |
| | Authors: |
Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. |
| | An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems |
| |
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. |
| | I2NSF Analytics Interface YANG Data Model for Closed-Loop Security Control in the I2NSF Framework |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-i2nsf-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. |
| | Secure SMTP/TLS SRV Announcement |
| |
|
This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. |
| | Recommendations for Key Directories over HTTP |
| |
|
This document defines recommendations for protocols that expose public keys over HTTP. |
| | Network Time Protocol Version 5 |
| |
|
This document describes the version 5 of the Network Time Protocol (NTP). |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-09.txt |
| | Date: |
13/02/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. |
| | SVGs in RFCs |
| |
| | draft-rossi-svgsinrfcs-01.txt |
| | Date: |
13/02/2025 |
| | Authors: |
Alexis Rossi, Nevil Brownlee, Jean Mahoney, Martin Thomson |
| | Working Group: |
RFC Series Working Group (rswg) |
|
This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from [RFC7996] and removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs. |
| | Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568. |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| | Shared Brotli Compressed Data Format |
| |
|
This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window and a container format to brotli (RFC 7932). Shared dictionaries and large window support allow significant compression gains compared to regular brotli. This document updates RFC 7932. |
| |
|
| |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | A YANG data model to manage configurable DWDM optical interfaces |
| |
| | draft-ietf-ccamp-dwdm-if-param-yang-12.txt |
| | Date: |
12/02/2025 |
| | Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) [ITU-T_G.698.2] or any other ITU-T recommendation. Use cases are described in [RFC7698]. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of DWDM interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. |
| | Additional Parameter sets for HSS/LMS Hash-Based Signatures |
| |
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | NETCONF Client and Server Models |
| |
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-02-12 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for this draft * JJJJ --> the assigned RFC value for draft-ietf-netconf-udp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-02-12 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | System-defined Configuration |
| |
|
The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This document introduces the concept of system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients. This document updates RFC 8342. |
| | Notable CBOR Tags |
| |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | NTS4PTP - Network Time Security for the Precision Time Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. It also provides measures against known attack vectors targeting PTP. |
| | Private Line Emulation over Packet Switched Networks |
| |
| | draft-ietf-pals-ple-15.txt |
| | Date: |
12/02/2025 |
| | Authors: |
Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Chris Brown |
| | Working Group: |
Pseudowire And LDP-enabled Services (pals) |
|
This document expands the applicability of virtual private wire services (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over packet switched networks (PSN). |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-07.txt |
| | Date: |
12/02/2025 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| | Topology Independent Fast Reroute using Segment Routing |
| |
|
This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. |
| | 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. |
| | Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings |
| |
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. |
| |
|
| |
| | BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
| |
| | draft-ietf-anima-brski-prm-18.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the Key Infrastructure (e.g., domain CA). |
| | YANG Data Model for BIER Protocol |
| |
| | draft-ietf-bier-bier-yang-10.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document defines a YANG data model that can be used to configure and manage devices supporting Bit Index Explicit Replication"(BIER). The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document describes the process to distribute Border Gateway Protocol- Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems. This document defines a new type within the BGP-LS NLRI for a Stub Link and three new type-length- values (TLVs) for BGP-LS Link descriptor. These additions to BGP-LS let Software Definition Network (SDN) controllers retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. |
| | SRv6 Deployment and Operation Problem Summary |
| |
| | draft-liu-srv6ops-problem-summary-04.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Yisong Liu, Dan Voyer, Thomas Graf, Zoltan Miklos, Luis Contreras, Nicolai Leymann, Linjian Song, Satoru Matsushima, Chongfeng Xie, Xinxin Yi |
| | Working Group: |
Individual Submissions (none) |
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. |
| | The Correspondence between Packets and SRv6 Tunnels |
| |
|
This paper introduces a new extension header, the SRv6 Policy Key, which addresses the issues of timeliness and accuracy in controller- aware path management within SRv6 networks. By adding a unique path identifier to the message header, this scheme enables network nodes to report path information to the controller. This ensures that the controller maintains a real-time and accurate view of the SR path status, even if the SID is lost during transmission or if the controller cannot monitor it in real time and accurately. The approach aims to enhance network availability and operational efficiency, particularly in scenarios involving multi-path tunnel configurations and load balancing. |
| | A Password Authenticated Key Exchange Extension for TLS 1.3 |
| |
| | draft-bmw-tls-pake13-01.txt |
| | Date: |
11/02/2025 |
| | Authors: |
Laura Bauman, David Benjamin, Samir Menon, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. |
| | Application State Components for More Instant Messaging Interoperability (MIMI) |
| |
|
This document presents structures for room metadata, participant lists, pre-authorized roles for future participants, and role-based access control, all of which are intended for use in MIMI (More Instant Messaging Interoperability). |
| | User Attributes in OpenPGP |
| |
|
This document updates the specification of User Attribute Packets and Subpackets in OpenPGP. |
| | Privacy Pass Reverse Flow |
| |
|
This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a reverse flow from the Origin to the Client/Attester/Issuer. It describes a way for redeeming Origins to perform new issuances in the same request. |
| | PCEP Extensions to support BFD parameters |
| |
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. |
| |
|
| |
| | Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations |
| |
|
The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFCs 5890 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. |
| | Absolute Capture Timestamp RTP header extension |
| |
|
This document describes an RTP header extension that can be used to carry information about the capture time of a video frame / audio sample, and include information that allows the capture time to be estimated by the receiver when the frame may have passed over multiple hops before reaching the receiver. |
| | Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) |
| |
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. |
| | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. |
| | Advertising Segment Routing Policies in BGP |
| |
| | draft-ietf-idr-sr-policy-safi-13.txt |
| | Date: |
06/02/2025 |
| | Authors: |
Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain |
| | Working Group: |
Inter-Domain Routing (idr) |
|
A Segment Routing (SR) Policy is an ordered list of segments (also referred to as instructions) that define a source-routed policy. An SR Policy consists of one or more candidate paths, each comprising one or more segment lists. A headend can be provisioned with these candidate paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP. This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths. Furthermore, this document updates RFC9012 by extending the Color Extended Community to support additional steering modes over SR Policy. |
| | Updated YANG Module Revision Handling |
| |
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. |
| | EAT Attestation Results |
| |
| | draft-fv-rats-ear-05.txt |
| | Date: |
06/02/2025 |
| | Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-07.txt |
| | Date: |
06/02/2025 |
| | Authors: |
Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Attestation Results for Secure Interactions |
| |
| | draft-ietf-rats-ar4si-08.txt |
| | Date: |
06/02/2025 |
| | Authors: |
Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. |
| | Static Context Header Compression (SCHC) Architecture |
| |
|
This document defines the SCHC architecture. |
| | Compressed SRv6 Segment List Encoding (CSID) |
| |
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. |
| |
|
| |
| | EVPN Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end-to-end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. |
| | A YANG Data Model for Transport Network Client Signals |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. |
| | A Network Data Model for Inventory Topology Mapping |
| |
|
This document defines a YANG model to map the network inventory data with the topology model to form a base underlay network. The model facilitates the correlation between the layer (e.g., Layer 2 and Layer 3) topology information and the inventory data of the underlay network for better service provisioning, network maintenance operations, and other assessment scenarios. |
| | Federated TLS Authentication |
| |
|
This document describes the Federated TLS Authentication (FedTLS) protocol, 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, FedTLS 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. |
| | Identity for E2E-Secure Communications |
| |
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. |
| | 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. |
| | Private Inexpensive Norm Enforcement (PINE) VDAF |
| |
|
This document describes PINE, a Verifiable Distributed Aggregation Function (VDAF) for secure aggregation of high-dimensional, real- valued vectors with bounded L2-norm. PINE is intended to facilitate private and robust federated machine learning. |
| | BMPS: Transport Layer Security for BGP Monitoring Protocol |
| |
|
The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates [RFC7854] regarding BMP session establishment and termination. |
| | Stateless Hash-Based Signatures for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of Sphincs+/SLH-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | SCHC Architecture for Process Stacking and Routing in Constrained Networks |
| |
|
This document specifies architectural guidelines for dynamically stacking and routing SCHC processes in constrained networks. It details how independent SCHC modules can be composed into processing chains that adapt to PDU attributes. For instance, SCHC Compression may trigger SCHC Fragmentation when the compressed PDU exceeds the L2 MTU, or alternatively, trigger SCHC Aggregation. For traffic that is not delay tolerant, a direct routing from SCHC Compression to SCHC Reliability Fragmentation is provided. Subsequent processing by SCHC FEC Fragmentation modules ensures robust error correction. This modular approach promotes scalability and flexibility within the SCHC framework. |
| | A comparative analysis of SCONE relative to TRAIN |
| |
|
A merge of the rate availability signaling schemes in the SCONE and TRAIN proposals is analysed and found to be infeasible. |
| | Lightweight Directory Access Protocol (LDAP): Additional Syntaxes |
| |
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes. |
| | Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension, "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) through RDAP. The Internet Number Registry System (INRS) is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| | Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management |
| |
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. |
| | The SSLKEYLOGFILE Format for TLS |
| |
|
A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. |
| |
|
| |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-12.txt |
| | Date: |
02/02/2025 |
| | Authors: |
Rishabh Parekh, Clarence Filsfils, Mankamana Mishra, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
| |
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also described. |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA |
| |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | MTU propagation over EVPN Overlays |
| |
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. |
| | Secure IP Binding Synchronization via BGP EVPN |
| |
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. |
| | Organization Trust Relationship Protocol |
| |
|
This document specifies the "Organization Trust Relationship Protocol" method for service owners (organizations) to express in a standard format their trusted relationships with other organizations, as well as identify the social networks they control. This method was originally defined by Scott Yates in 2020 for this purpose. |
| | DKIM Hash Algorithm Adaptivity |
| |
|
DKIM (RFC 6376, section 3.7) defines how "data-hash" is generated as input to a "sig-alg" for the purpose of generating a cryptographic signature. Different to the RSA algorithm (RFC 8017) solely defined for and by DKIM at the time of its creation, modern signature algorithms, for example EdDSA (RFC 8032), include extensive data hashing as part of the signing process. For these algorithms it may make sense not to create a "data-hash", but to use the entire data as input to "sig-alg". This specification allows DKIM signing algorithms "data-hash" adaptivity, taking advantage of algorithm design, and digital signature API reality. |
| | DKIM Signing Algorithm AdaEd25519-SHA256 |
| |
|
This specification adds the DKIM (RFC 6376) signing algorithm AdaEd25519-SHA256. It is identical to Ed25519-SHA256 (RFC 8463) except for its use of DKIM hash algorithm adaptivity. Private and public keys are identical, and can be used interchangeably. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-11.txt |
| | Date: |
02/02/2025 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, Mankamana Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments. A SR Point-to-Multipoint (SR P2MP) Policy defines a P2MP tree and a PCE computes and instantiates the tree. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. |