| |
|
| |
| | Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension |
| |
| | draft-ietf-acme-ari-04.txt |
| | Date: |
31/05/2024 |
| | 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. |
| | IANA Registrations for the BGP Finite State Machine (FSM) |
| |
|
The Border Gateway Protocol, version 4 (BGP-4) finite state machine (FSM) is defined in RFC 4271. Over the years, various extensions to BGP have been authored that update the protocol's FSM. Some elements of the FSM are enumerated. Those elements are referred to across BGP extensions in their respective state machine changes, and may also be used for management purposes in things such as YANG (RFC 7950). To provide consistent naming and enumeration of these FSM elements, this document requests IANA to create and maintain registries for elements in the BGP FSM. |
| | Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media |
| |
|
This document describes RTCP messages and RTP header extensions to enable partial access and support viewport- and region-of-interest- dependent delivery of visual volumetric media such as visual volumetric video-based coding (V3C). Partial access refers to the ability to access retrieve or deliver only a subset of the media content. The RTCP messages and RTP header extensions described in this document are useful for XR services which transport coded visual volumetric content, such as point clouds. |
| | Joint Exposure of Network and Compute Information for Infrastructure-Aware Service Deployment |
| |
|
Service providers are starting to deploy computing capabilities across the network for hosting applications such as distributed AI workloads, AR/VR, vehicle networks, and IoT, among others. In this network-compute environment, knowing information about the availability and state of the underlying communication and compute resources is necessary to determine both the proper deployment location of the applications and the most suitable servers on which to run them. Further, this information is used by numerous use cases with different interpretations. This document proposes an initial approach towards a common exposure scheme for metrics reflecting compute and communication capabilities. |
| | 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. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. |
| | Use Cases for a PCE as a Central Controller (PCECC) |
| |
| | draft-ietf-teas-pcecc-use-cases-18.txt |
| | Date: |
31/05/2024 |
| | Authors: |
Zhenbin Li, Dhruv Dhody, Quintin Zhao, Zekung Ke, Boris Khasanov |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. PCE was developed to derive traffic-engineered paths in MPLS networks, which are supplied to the head end of the paths using the Path Computation Element Communication Protocol (PCEP). SDN has much broader applicability than signaled MPLS traffic- engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions which are required for the PCECC use cases are covered in separate documents. |
| |
|
| |
| | The IPv6 Compact Routing Header (CRH) |
| |
|
This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, can be addressed with access control lists. Finally, this document encourages replication of the experiment. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet Extension Headers |
| |
|
Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By-Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IPv6 extension headers and MPLS Network Action Sub-Stacks, for example, for hop-by-hop and edge-to-edge active measurements, including using IOAM data fields. |
| | Requirements for Solutions that Support MPLS Network Actions (MNA) |
| |
|
This document specifies requirements for the development of MPLS Network Actions (MNA) which affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER). |
| | NETCONF Private Candidates |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | ICANN Registry Interfaces |
| |
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Peering API |
| |
|
We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. |
| | ICMP Extensions for Environmental Information |
| |
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental sustainability information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental sustainability metrics. |
| | Knowledge Graphs for YANG-based Network Management |
| |
|
The success of the YANG language and YANG-based protocols for managing the network has unlocked new opportunities in network analytics. However, the wide heterogeneity of YANG models hinders the consumption and analysis of network data. Besides, data encoding formats and transport protocols will differ depending on the network management protocol supported by the network device. These challenges call for new data management paradigms that facilitate the discovery, understanding, integration and access to silos of heterogenous YANG data, abstracting from the complexities of the network devices. This document introduces the knowledge graph paradigm has a solution to this data management problem, with focus on YANG-based network management. The document provides background on related topics such as ontologies and graph standards, and shares guidelines for implementing knowledge graphs from YANG data. |
| | YANG Data Model for SR Policy Group |
| |
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. |
| |
|
| |
| | Signalling DHCPv6 Prefix Delegation Availability to Hosts |
| |
|
This document defines a "P" flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that clients do not use the prefix provided in the PIO for SLAAC but request a prefix via DHCPv6 PD instead, and use that delegated prefix to form addresses. |
| | Media over QUIC Transport |
| |
| | draft-ietf-moq-transport-04.txt |
| | Date: |
29/05/2024 |
| | Authors: |
Luke Curley, Kirill Pugin, Suhas Nandakumar, Victor Vasiliev, Ian Swett |
| | Working Group: |
Media Over QUIC (moq) |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Extensions to the Access Control Lists (ACLs) YANG Model |
| |
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. |
| | SMTP Service Extension for Client Identity |
| |
|
This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CLIENTID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. |
| | IMAP Service Extension for Client Identity |
| |
|
This document defines an Internet Message Access Protocol (IMAP) service extension called "CLIENTID" which provides a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. |
| | PEM file format for ECH |
| |
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. |
| | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. |
| | Considerations on RFC 9537 |
| |
|
This document discusses client implementation issues relating to RFC 9537, “Redacted Fields in the Registration Data Access Protocol (RDAP) Response”. The considerations in this document have arisen from problems raised by two separate teams attempting to implement RFC 9537 in both an RDAP web client and an RDAP command line client. Some of these problems may be insurmountable, leaving portions of RFC 9537 non-interoperable between clients and servers, while other problems place a high degree of complexity upon clients. |
| | Route Origin Registry Problem Statement |
| |
|
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin ASes (MOAS), higher requirements are placed on the route origin registry system. This document serves to outline the problem statement for current route origin registry system. |
| | YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) |
| |
|
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. |
| |
|
| |
| | BFD Encapsulated in Large Packets |
| |
|
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. |
| | Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator |
| |
|
This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] |
| | Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
| | draft-ietf-lamps-cms-sphincs-plus-05.txt |
| | Date: |
28/05/2024 |
| | Authors: |
Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas Westerbaan |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| | MPLS Network Action for Deterministic Latency |
| |
|
This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains. |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-04.txt |
| | Date: |
28/05/2024 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. |
| |
|
| |
| | An Architecture for DNS-Bound Client and Sender Identities |
| |
| | draft-ietf-dance-architecture-06.txt |
| | Date: |
27/05/2024 |
| | Authors: |
Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson |
| | Working Group: |
DANE Authentication for Network Clients Everywhere (dance) |
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. |
| | Deterministic Networking (DetNet) Controller Plane Framework |
| |
|
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. |
| | The Idempotency-Key HTTP Header Field |
| |
|
The HTTP Idempotency-Key request header field can be used to carry idempotency key in order to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. |
| | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane |
| |
| | draft-ietf-mpls-sr-epe-oam-17.txt |
| | Date: |
27/05/2024 |
| | Authors: |
Shraddha Hegde, Mukul Srivastava, Kapil Arora, Samson Ninan, Xiaohu Xu |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Egress Peer Engineering (EPE) is an application of Segment Routing to solve the problem of egress peer selection. The Segment Routing based BGP-EPE solution allows a centralized controller, e.g. a Software Defined Network (SDN) controller to program any egress peer. The EPE solution requires the node or the SDN controller to program the PeerNode Segment Identifier(SID) describing a session between two nodes, the PeerAdj SID describing the link (one or more) that is used by sessions between peer nodes, and the PeerSet SID describing any connected interface to any peer in the related group. This document provides new sub-TLVs for EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and Traceroute procedures. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | JSON semantic format (JSON-NTV) |
| |
|
This document describes a set of simple rules for unambiguously and concisely encoding semantic data into JSON Data Interchange Format. These rules are based on an NTV (Named and Typed Values) data structure applicable to any simple or complex data. The JSON-NTV format is its JSON translation. |
| | LibrePGP Message Format |
| |
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| | The Asynchronous Remote Key Generation (ARKG) algorithm |
| |
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. |
| | Operations,Administration and Maintenance (OAM) data collection for service decision-making in Computing-Aware Traffic Steering |
| |
|
This document describes the collection of OAM data for services decision-making in Computing-Aware Traffic Steering.In the following section, the main functional components and processes of OAM data collection will be elaborated in detail. |
| | Media over QUIC - Transfork |
| |
|
TODO Abstract Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Media Over QUIC Working Group mailing list (moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Source for this draft and an issue tracker can be found at https://github.com/kixelated/moq-transfork. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-03.txt |
| | Date: |
27/05/2024 |
| | 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-SHAKE (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Path Computation Element Protocol(PCEP) Extension for Color |
| |
| | draft-ietf-pce-pcep-color-04.txt |
| | Date: |
27/05/2024 |
| | Authors: |
Balaji Rajagopalan, Vishnu Beeram, Shaofu Peng, Mike Koldychev, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g. low latency). This document specifies an extension to Path Computation Element Protocol (PCEP) to carry the color attribute. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-11.txt |
| | Date: |
27/05/2024 |
| | 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 types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| |
|
| |
| | CDNI Capacity Capability Advertisement Extensions |
| |
|
The CDNI Capacity Capability Advertisement Extensions define a set of additional Capability Objects that provide information about current dCDN utilization and specified usage limits to the delegating uCDN in order to inform traffic delegation decisions. This document supplements the CDNI Capability Objects defined in RFC 8008 with two additional Capability Objects: FCI.CapacityLimits and FCI.Telemetry. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-07.txt |
| | Date: |
26/05/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-06.txt |
| | Date: |
26/05/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Inter-domain Source Address Validation (SAVNET) Architecture |
| |
|
This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. |
| | Security Profiles in Bootstrap Voucher Artifacts |
| |
|
This document describes an extension of the RFC8366 Voucher Artifact in order to support security profiles. This allows the owner to change and customize the security posture of the device dynamically and securely. This lets the owner to selectively enable or disable each of the underlying security parameters that make up the security posture of the device. |
| | Naming the Protocol specified RFC 8029 |
| |
|
RFC 8029 specifies the key MPLS Operation, Administration, and Maintenance protocol, sometimes referred to MPLS Label Switched Path (LSP) Ping, or MPLS LSP Ping. Howerver, the actual name of the protocol have never been explicitly specified or documented. This document corrects that omission. This document updatess RFC 8029. |
| |
|
| |
| | Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks |
| |
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables IP packet stateless forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is static, the location of the nodes is fixed, and the connection between the nodes is also rather stable. This specifications describes the PASA architecture, along with PASA address allocation, forwarding mechanism, header format design, and IPv6 interconnection support. |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also briefly mentioned. |
| | Border Gateway Protocol 4 (BGP-4) Send Hold Timer |
| |
|
This document defines the SendHoldtimer, along with the SendHoldTimer_Expires event, for the Border Gateway Protocol (BGP) Finite State Machine (FSM). Implementation of the SendHoldTimer helps overcome situations where a BGP connection is not terminated after the local system detects that the remote system is not processing BGP messages. This document specifies that the local system should close the BGP connection and not solely rely on the remote system for connection closure when the SendHoldTimer expires. This document updates RFC4271. |
| | Software Version Capability for BGP |
| |
|
In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. |
| | Multicast VPN Upstream Designated Forwarder Selection |
| |
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. |
| | Generalized Arguments of SRv6 Segment |
| |
|
This document analyzes the challenges of Arguments of SRv6 SID, and the chance of using Arguments of SRv6 SID to reduce the length of the IPv6 extension header. According to these analysis, this document specifies a kind of generalized and structured Arguments for SRv6 SID, which can carry multiple Arguments parts for a SRv6 SID. |
| | SPKI S-Expressions |
| |
| | draft-rivest-sexp-09.txt |
| | Date: |
24/05/2024 |
| | Authors: |
Ronald Rivest, Donald Eastlake |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies a data structure representation that is suitable for representing arbitrary, complex data structures. It was devised in 1996/1997 to support SPKI (RFC 2692) certificates with the intent that it be more widely applicable. It has been and is being used elsewhere. There are many implementations in a variety of programming languages. Uses of this representation herein are referred to as "S-expressions". This memo makes precise the encodings of these S-expressions: it gives a "canonical form" for them, describes two "transport" representations, and also describe an "advanced" format for display to people. |
| | 464 Customer-side Translator (CLAT): Node Recommendations |
| |
|
464XLAT ([RFC6877]) defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document provides recommendations on when a node shall enable or disable CLAT. |
| | OpenPGP Replacement Key Signalling Mechanism |
| |
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated key. |
| | A Formalization of Symbolic Expressions |
| |
|
The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. |
| | Resilient Cycle Queuing and Forwarding |
| |
|
The document proposes a solution called Resilient Cycle Queuing and Forwarding (RCQF) for DetNet extremely low data loss rates, bounded latency and minimal jitter. RCQF is a technological advancement built upon Cycle Queuing and Forwarding (CQF), designed to provide a capability for the delivery of end-to-end DetNet flows. RCQF extends the capabilities of CQF and makes it suitable for large scaling networks. The elasticity of RCQF includes adaptive bonded latency, minimal jitter, high bandwidth, large packet size, interface speed, and only requires frequency synchronization. This document aims to introduce the concept of RCQF and its potential in providing resilient and adaptable solutions for Deterministic Networks. |
| | An Information Model for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-01.txt |
| | Date: |
24/05/2024 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The primary function of a network is to transport packets and deliver them according to a service level objective. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Device-reported packet loss is the most direct signal for network operations to identify customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss. |
| | Hybrid signature spectrums |
| |
|
This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatiblity, hybrid generality, and simultaneous verification. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums |
| |
|
| |
| | Architecture and Framework for IPv6 over Non-Broadcast Access |
| |
|
This document presents an architecture for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. |
| | Simple Mail Transfer Protocol |
| |
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and a list of DNS zones that are accessible via a proxy. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. |
| | Programming Methodology Framework aka PMF |
| |
|
This document describes the Programming Methodology Framework also known under the PMF methodology. The methodology is based on the manifesto written by Zed A. Shaw [PROGRAMMING-MF-MANIFESTO] which describes a natural approach to software engineering with a strong focus on the act of programming. The PMF methodology uses a soft naming to allow for a non-partisan reference to official engineering or project documents describing one of the most used software engineering methodologies. |
| | LTP Performance Maximization |
| |
|
The Licklider Transmission Protocol (LTP) provides a reliable datagram convergence layer for the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol. In common practice, LTP is often configured over UDP/IP sockets and inherits its maximum segment size from the maximum-sized UDP/IP datagram, however when this size exceeds the path maximum transmission unit a service known as IP fragmentation must be engaged. This document discusses performance maximization implications of LTP interactions with large packet sizes and IP fragmentation. |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-09.txt |
| | Date: |
23/05/2024 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches |
| |
|
MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. |
| | SR based Loop-free implementation |
| |
|
Microloops are transient packet loops that occur in the network following a topology change (link- down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If a converged node sends traffic to a neighbor node that has not converged yet (or vice versa), traffic may be looped between these nodes, resulting in packet loss, jitter, and packet disorder. This document presents some optional implementation methods aimed at loop avoidance in different scenarios of IGP network convergence. |
| | QUIC Accurate ECN Acknowledgements |
| |
|
QUIC defines a variant of the ACK frame that carries cumulative count for each of the three ECN codepoints (ECT(1), ECT(0) and CE). From this information, the recipient of the ACK frame cannot deduce which ECN marking the individual packets were received with. This document defines an alternative ACK frame that encodes enough information to indicate which ECN mark each individual packet was received with. This information is essential for accurately performing adjustments to congestion window and sending rate of the sender. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Implementation of RFC Publication Formats |
| |
|
This document assigns responsibility for implementation decisions for RFC publication formats (currently HTML, PDF, and TXT), the CSS file, and SVG files to a tools implementation team and the RPC. It assigns responsibility for defining high level design requirements for the RFC publication formats, CSS, and SVG files to the RSWG. This document updates RFC7992, RFC7993, RFC7994, RFC7995, RFC7996 and RFC9280. This document makes no changes to the RFCXML format described in RFC7991 or subsequent documents. |
| | SCONEPRO Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-sconepro-ecn-01.txt |
| | Date: |
23/05/2024 |
| | Authors: |
Anoop Tomar, Marcus Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONEPRO use-case. The SCONEPRO objective is to optimize user QoE for streaming media/ video services through network assisted application-level self- adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | Efficient RDAP Referrals |
| |
|
This document describes how RDAP servers can provide HTTP "Link" header fields in RDAP responses to allow RDAP clients to efficiently determine the URL of related RDAP records for a resource. |
| | Export of UDP Options Information in IP Flow Information Export (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. |
| | RIFT: Routing in Fat Trees |
| |
| | draft-ietf-rift-rift-24.txt |
| | Date: |
23/05/2024 |
| | Authors: |
Tony Przygienda, Jordan Head, Alankar Sharma, Pascal Thubert, Bruno Rijsman, Dmitry Afanasiev |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects, and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well. The protocol specified by this document is optimized toward the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for simplified deployment of said topologies. |
| | 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. |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| |
|
| |
| | Transmission of IPv6 Packets over Short-Range Optical Wireless Communications |
| |
| | draft-ietf-6lo-owc-00.txt |
| | Date: |
22/05/2024 |
| | 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. 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. |
| | Requirements for Scaling Deterministic Networks |
| |
|
Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. |
| | Applicability of BGP-LS with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (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. When Segment Routing is used as the data plane of NRPs, each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to distribute the information of SR based NRPs using BGP-LS with Multi-Topology (MT). |
| | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
RFC 8954 imposed the size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document updates the maximum allowed length of Nonce to 128 octets. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960. |
| | EVPN Mpls Ping Extension |
| |
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. |
| | Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers |
| |
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. |
| | IPv4 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs and a new link model for Internetworking. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. |
| | IPv6 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing only a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of- packets", while AJs offer essential operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Network (DTN) link model. |
| | IPv6 Extended Fragment Header for IPv4 |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. |
| | Clarification of IPv6 Address Assignment Policy |
| |
|
This document specifies the approval process for changes to the IPv6 Address Space registry. It also updates RFC 7249. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-6man-addr-assign/. Discussion of this document takes place on the 6MAN Working Group mailing list (mailto:ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/. Subscribe at https://www.ietf.org/mailman/listinfo/ipv6/. |
| | Parental Reource Record Types in DNS |
| |
|
This document updates the DNS Parameters' Resource Record (RR) TYPEs registry by adding a field denotating "Parental RRtype" that instructs DNS name servers to store or query RRtypes that have this new field set at the parent side of a delegation instead of at the child side. These DNS protocol rules match those already in use for the Delegation Signer (DS) RRtype. It additonally reserves a small part of the "Reserved for future use" allocation space in the RRtype registry to mark a group of RRtypes values to have this new flag set. The goal of this document is to provide a general facility that future RRtypes can use without requiring to wait a period of many years for DNS implementations and deployments before these type of new RRtype become usable in practise. It is similar in goal to the support of Unknown DNS RRtypes as specified in RFC 3597. This document updates [many things which we should figure out]. |
| | Updates to the The Delegation Server (DS) Record |
| |
|
This document updates the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms IANA Registry to carry two new non-digest algorithm entries. The first new type value creates a generic method to embed a Parental RRtype within the DS record. The second new type value creates an Alias DS record to point to the actual DS record published in a different DNSSEC signed zone under DNS Provider change control. The DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry is renamed to the DNSSEC Delegation Signal Registry. This document updates [many things which we should figure out]. |
| | Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 |
| |
| | draft-ietf-opsawg-tacacs-tls13-10.txt |
| | Date: |
22/05/2024 |
| | Authors: |
Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC8907. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
| | draft-ietf-roll-enrollment-priority-11.txt |
| | Date: |
22/05/2024 |
| | Authors: |
Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| |
|
| |
| | QUIC-Aware Proxying Using HTTP |
| |
| | draft-ietf-masque-quic-proxy-02.txt |
| | Date: |
21/05/2024 |
| | Authors: |
Tommy Pauly, Eric Rosenberg, David Schinazi |
| | Working Group: |
Multiplexed Application Substrate over QUIC Encryption (masque) |
|
This document defines an extension to UDP Proxying over HTTP that adds specific optimizations for proxied QUIC connections. This extension allows a proxy to reuse UDP 4-tuples for multiple connections. It also defines a mode of proxying in which QUIC short header packets can be forwarded using an HTTP/3 proxy rather than being re-encapsulated and re-encrypted. |
| | mLDP Extensions for Multi-Topology Routing |
| |
|
Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP (Multipoint label distribution protocol) in a network that supports MTR, FA, or other methods of signaling non-default IGP algorithms, mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support MTR, with an algorithm, in order for Multipoint LSPs(Label Switched Paths) to follow a particular topology and algorithm. It updates [RFC7307] by allocating eight bits from a previously reserved field to be used as the IGP Algorithm (IPA) field. |
| | Advertising SID Algorithm Information in BGP |
| |
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. |
| | Mailing List Manager (MLM) Transformations |
| |
|
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to rewrite the From: header field as a workaround. This document proposes a method to revert MLM transformations, in order to restore the original From: line after reception. There are two strategies to undo From: rewriting, author-centric, whereby the signing agent takes measures for undoing, and list- centric, whereby the MLM does so. The present method uses the former strategy. |
| | Closing the RTP Payload Format Media Types IANA Registry |
| |
|
It has been observed that specifications of new RTP payload formats often forget to register themselves in the IANA registry "RTP Payload Formats Media Types". In practice this has no real impact. One reason is that the Media Types registry is the crucial registry to register any Media Type to establish the media type used to identified the format in various signaling usage. To resolve this situation this document performs the following. First it updates the registry to include known RTP payload formats at the time of writing. Then it closes the IANA Registry for RTP Payload formats Media Types for future registration. Beyond instructing IANA to close this registry the instructions to authors in RFC 8088 are updated that registration is no longer required in the closed registry. |
| | Problem Statement for Digitized Emblems |
| |
|
International law defines a number of emblems, such as the blue helmets of United Nations peacekeeping forces, the blue and white shield of UNESCO, and the Red Cross of the International Committee of the Red Cross, as indicative of special protections under the Geneva Conventions. Similar protections attach to journalists who wear "Press" protective emblems on the battlefield, under Article 79 of Protocol I of the Geneva Conventions and Resolution 2222 of the United Nations Security Council. The emblems of national governments and inter-governmental organizations protect diplomatic pouches, couriers, and envoys under the Vienna Convention on Diplomatic Relations. Other marks enjoy protections against mis-use under the Paris Convention, the Madrid Protocol, and the Trade-Related Aspects of Intellectual Property Rights. Such physical emblems have a number of weaknesses and do not translate to the digital realm. This document provides a summary of the problems and documents identified requirements from a number of stakeholders for a digital emblem which addresses the shortcomings of the physical emblems and makes possible the indication of protections of digital assets under international law. |
| | 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. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [I-D.ietf-emu-aka-pfs], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ- KEMs). |
| | Relying Party Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions |
| |
|
This document clarifies how Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) handle Certificate Revocation List (CRL) Number extensions. This document updates RFC 6487. |
| | Source Address Validation in OSPF Networks |
| |
|
This document proposes a comprehensive intra-domain Source Address Validation (SAV) solution to deal with different source address spoofing scenarios. It can be applied to networks running OSPFv2 and OSPFv3. The Source Prefix Validation Sub-TLV is defined to support automatic SAV-specific information exchanging between area-local routers, which helps routers generate accurate SAV rules to verify the validity of data packets. |
| | 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. |
| | Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry |
| |
|
This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix shortcomings in the description of some Information Elements (IE), updates to ensure a consistent structure when citing an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. |
| | A YANG Data Model for Path Computation Element Communications Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-yang-25.txt |
| | Date: |
21/05/2024 |
| | Authors: |
Dhruv Dhody, Vishnu Beeram, Jonathan Hardwick, Jeff Tantsura |
| | Working Group: |
Path Computation Element (pce) |
|
This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data. |
| | Distributed Aggregation Protocol for Privacy Preserving Measurement |
| |
| | draft-ietf-ppm-dap-11.txt |
| | Date: |
21/05/2024 |
| | Authors: |
Tim Geoghegan, Christopher Patton, Brandon Pitman, Eric Rescorla, Christopher Wood |
| | Working Group: |
Privacy Preserving Measurement (ppm) |
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-04.txt |
| | Date: |
21/05/2024 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The presence of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, since the assumptions about the intractability of the mathematical problems for these algorithms that offer confident levels of security today no longer apply in the presence of a CRQC. This means there is a requirement to update protocols and infrastructure to use post-quantum algorithms, which are public-key algorithms designed to be secure against CRQCs as well as classical computers. These new public-key algorithms behave similarly to previous public key algorithms, however the intractable mathematical problems have been carefully chosen so they are hard for CRQCs as well as classical computers. This document explains why engineers need to be aware of and understand post-quantum cryptography. It emphasizes the potential impact of CRQCs on current cryptographic systems and the need to transition to post-quantum algorithms to ensure long-term security. The most important thing to understand is that this transition is not like previous transitions from DES to AES or from SHA-1 to SHA-2. While drop-in replacement may be possible in some cases, others will require protocol re-design to accommodate significant differences in behavior between the new post-quantum algorithms and the classical algorithms that they are replacing. |
| | Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) |
| |
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. |
| |
|
| |
| | RTP Payload for Haptics |
| |
|
This memo describes an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS(MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. |
| | Meticulous Keyed ISAAC for BFD Authentication |
| |
|
This document describes a new BFD Authentication mechanism, Meticulous Keyed ISAAC. This mechanism can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used as an authenticated signal to maintain a session in the the "Up" state. This document updates RFC 5880. |
| | Performance Measurement with Asymmetrical Packets in STAMP |
| |
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | Terminology and Use cases for Secured Routing Infrastructure |
| |
|
This document collects terminology and use cases for Secured Routing. |
| | APIs To Expose SCONEPRO Metadata to Applications |
| |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using the SCONEPRO protocol (to be defined by the IETF), it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. |
| | legacy modularity usage for eco-conception |
| |
|
This draft discusses the usage of inventory information for assessing the adaptation of existing devices to eco-design. It is driven by the weight of the manufacturing in the sustainability cost with regard to the power consumption. |
| | 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. |
| | Device Schema Extensions to the SCIM model |
| |
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wifi EasyConnect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. |
| |
|
| |
| | SR Policies Extensions for Network Resource Partition in BGP-LS |
| |
|
A Network Resource Partition (NRP) is a network resource attribute associated with the SR policy. It is also an important attribute of the SR policy and needs to be reported to the external components. This document defines a new TLV which enable the headend to report the configuration and the states of an SR policy carrying the NRP information by using BGP-LS. |
| | Using onion routing with CoAP |
| |
|
The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and client similar to how Tor (The Onion Router) enables it for TCP based protocols. |
| | SCONEPRO Net Neutrality |
| |
|
This document provides a response to the question of whether SCONEPRO can be used to undermine Net Neutrality provisions for network users. It proposes guardrails to ensure Net Neutrality principles are maintained. |
| | The Distributed Symmetric Key Establishment (DSKE) Protocol |
| |
| | draft-mwag-dske-00.txt |
| | Date: |
17/05/2024 |
| | Authors: |
Mattia Montagna, Manfred von Willich, Melchior Aelmans, Gert Grammel |
| | Working Group: |
Individual Submissions (none) |
|
The Distributed Symmetric Key Establishment (DSKE) protocol introduces an approach to symmetric key distribution that enables robust, scalable, and future-proofed security without reliance on asymmetric encryption. This document delineates the protocol's specifications, security model, and architectural integration. Note This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. |
| | SCONEPRO Video Optimization Requirements |
| |
|
These are the requirements for the "Video Optimization" use-case for the SCONEPRO topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. |
| | Considerations For Using Unique Local Addresses |
| |
|
This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them. |
| |
|
| |
| | IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription |
| |
|
This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address; the document updates the Routing Protocol for Low-Power and Lossy Networks (RFC 6550, RFC 6553) to add a new Non-Storing Multicast Mode and a new support for anycast addresses in Storing and Non-Storing Modes. This document extends RFC 9010 to enable a 6LoWPAN Router to inject the anycast and multicast addresses in RPL. |
| | RTP Payload Format for sub-codestream latency JPEG 2000 streaming |
| |
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given codestream can be emitted before the entire codestream is available. |
| | Registering Self-generated IPv6 Addresses using DHCPv6 |
| |
| | draft-ietf-dhc-addr-notification-13.txt |
| | Date: |
16/05/2024 |
| | Authors: |
Warren Kumari, Suresh Krishnan, Rajiv Asati, Lorenzo Colitti, Jen Linkova, Sheng Jiang |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses. |
| | Sieve Email Filtering: Extension for Processing Calendar Attachments |
| |
| | draft-ietf-extra-processimip-07.txt |
| | Date: |
16/05/2024 |
| | Authors: |
Kenneth Murchison, Ricardo Signes, Matthew Horsfall |
| | Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME). |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-04.txt |
| | Date: |
16/05/2024 |
| | Authors: |
Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras |
| | Working Group: |
Global Routing Operations (grow) |
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. |
| | 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. |
| | Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS) |
| |
|
This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or part of a key derivation function. |
| | OAuth Profile for Open Public Clients |
| |
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. |
| | Problem statements and requirements of Deterministic CATS on the Industrial Internet |
| |
|
The Industrial Internet is a new infrastructure, application mode and industrial ecology with the deep integration among the new information technology, communication technology and the industrial economy.Industrial production tasks are time-sensitive, which put forward high requirements on networks and applications, and need to meet the deterministic requirements in terms of delay, jitter, reliability, etc. Industrial deterministic service refers to a closed loop composed of communication paths and control processes in which two or more applications participate.Industrial management platforms need to unify network forwarding and computing tasks for each deterministic service. This draft illustrates use cases of traffic steering for deterministic service in terms of dynamic computing and networking resource status,together with the requirements and solutions for CATS(Computing-Aware Traffic Steering). |
| | Updating the NTP Registries |
| |
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries, and makes updates where necessary. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. |
| | PCEP extensions for Distribution of Link-State and TE Information |
| |
| | draft-ietf-pce-pcep-ls-01.txt |
| | Date: |
16/05/2024 |
| | Authors: |
Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension. |
| | Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
| |
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
| | Compressed SRv6 Segment List Encoding |
| |
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SR segment endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 SID list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. |
| |
|
| |
| | The JMAPACCESS Extension for IMAP |
| |
|
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via JMAP, and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. |
| | A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) |
| |
| | draft-spinosa-urn-lex-22.txt |
| | Date: |
15/05/2024 |
| | Authors: |
PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a Uniform Resource Name (URN) Namespace Identifier for identifying, naming, assigning, and managing persistent resources in the legal domain. This specification is published to allow adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain. This specification is an independent submission to the RFC series. It is not a standard, and does not have the consensus of the IETF. |
| | BGP Extensions of SR Policy for Headend Behavior |
| |
|
This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. |
| | Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members |
| |
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document outlines how post-quantum digital signatures, specifically Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA), can be employed as authentication methods within the IKEv2 protocol. It introduces ML- DSA and SLH-DSA capability to IKEv2 without necessitating any alterations to existing IKE operations. |
| | A Network YANG Data Model for Attachment Circuits |
| |
|
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). |
| | RPKI Signed Object for Trust Anchor Key |
| |
| | draft-ietf-sidrops-signed-tal-16.txt |
| | Date: |
15/05/2024 |
| | Authors: |
Carlos Martinez, George Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein |
| | Working Group: |
SIDR Operations (sidrops) |
|
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current public key to RPs, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation. |
| |
|
| |
| | Segment Routing Path MTU in BGP |
| |
|
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 SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. |
| | Deterministic Route Redistribution into BGP |
| |
|
In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. To eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. Additionally, We recommend automatically lowering the LOCAL_PREF value in implementation for the redistributed backup route when appropriate. |
| | IPv6 Source Routing for ultralow Latency |
| |
|
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for ultralow latency source routing experimentation using simple forwarding nodes. The "6Tree" Network based on this addrssing scheme is described as well as possible applications. |
| | BGP SR Policy Extensions for template |
| |
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. |
| | Remove SHA-1 from active use within DNSSEC |
| |
|
This document retires the use of SHA-1 within DNSSEC. |
| | DNSSEC Cryptographic Algorithm Recommendation Update Process |
| |
|
[EDITOR NOTE: This document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in [RFC8624]; that is the work of future documents. Instead, this document moves the canonical list of algorithms from [RFC8624] to an IANA registry. This is done for two reasons: 1) to allow the list to be updated more easily, and, much more importantly, 2) to allow the list to be more easily referenced.] The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates [RFC8624] by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from [RFC8624] to an IANA registry. Future extensions to this registry can be made under new, incremental update RFCs. |
| | X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE |
| |
|
This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM, for HPKE (RFC9180). This KEM does not support the authenticated modes of HPKE. |
| | Remove ECC-GOST from use within DNSSEC |
| |
|
This document retires the use of ECC-GOST within DNSSEC. |
| | Customer Experience Index for Evaluating Network Quality for Cloud Applications |
| |
| | draft-hz-ippm-cei-01.txt |
| | Date: |
14/05/2024 |
| | Authors: |
Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Hongyi Huang, Tianran Zhou, Jian Ge, KE Ma |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network. |
| | The OAuth 2.1 Authorization Framework |
| |
| | draft-ietf-oauth-v2-1-11.txt |
| | Date: |
14/05/2024 |
| | Authors: |
Dick Hardt, Aaron Parecki, Torsten Lodderstedt |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. |
| | A Common YANG Data Model for Attachment Circuits |
| |
| | draft-ietf-opsawg-teas-common-ac-11.txt |
| | Date: |
14/05/2024 |
| | Authors: |
Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. |
| | Path Segment for SRv6 (Segment Routing in IPv6) |
| |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment has been defined to identify an SR path in SR-MPLS networks, and is used for various use-cases such as end-to- end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the Path Segment to identify an SRv6 path in an IPv6 network. |
| |
|
| |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-09.txt |
| | Date: |
13/05/2024 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an measurement that would result in an invalid aggregate result. |
| | IS-IS Fast Flooding |
| |
| | draft-ietf-lsr-isis-fast-flooding-11.txt |
| | Date: |
13/05/2024 |
| | Authors: |
Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Gunter Van de Velde, Tony Przygienda |
| | Working Group: |
Link State Routing (lsr) |
|
Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. |
| | Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) |
| |
|
Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct the egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system to request that the remote BFD peer transmits BFD control packets over the specified LSP. |
| | Path Tracing in SR-MPLS networks |
| |
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | PIM Light |
| |
| | draft-ietf-pim-light-03.txt |
| | Date: |
13/05/2024 |
| | Authors: |
Hooman Bidgoli, Stig Venaas, Mankamana Mishra, Zhaohui Zhang, Mike McBride |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document specifies a new Protocol Independent Multicast interface which does not need PIM Hello to accept PIM Join/Prunes. |
| |
|
| |
| | Open Ethics Transparency Protocol |
| |
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Format is an extensible JSON-based format. |
| | 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. |
| | BGP Flow Specification Version 2 - for Basic IP |
| |
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft. The IDR WG requires two implementation so This document is the first of the series of documents indicating the basic FSv2 with user ordering of filters added to FSv1 IP Filters and IP actions. |
| | BGP Flow Specification Version 2 - More IP Filters |
| |
|
The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft suggests additional IP Filters for Flow Specification FSv2. |
| | OAuth 2.0 Delegated B2B Authorization |
| |
|
Delegated B2B Authorization enables a third-party OAuth client to obtain a limited access to an HTTP service on behalf of another OAuth client which is acting as a resource owner. This specification extends the OAuth 2.0 Authorization Framework with two new endpoints which allow a resource owner OAuth client to manage access for a third-party OAuth client. |
| |
|
| |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-09.txt |
| | Date: |
10/05/2024 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document defines a new PKCS#10 attribute attr-evidence and CRMF extension ext-evidence that allows placing any Evidence data, in any pre-existing format, along with any certificates needed to validate it, into a PKCS#10 or CRMF CSR. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). |
| | 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. |
| | PQ/T Hybrid Key Exchange in SSH |
| |
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on traditional ECDH key exchange and post- quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| | 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. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | Guidelines for Charactering "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM acronym. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM acronym, and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". |
| | Reverse CoA in RADIUS |
| |
|
This document defines a "reverse change of authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. |
| | Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 services(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in one multi- domain underlay network. It lists the requirements of service traffic, illustrates major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery. The document also discusses related security considerations. |
| |
|
| |
| | 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. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-39.txt |
| | Date: |
09/05/2024 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | YANG Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | Terminology for Post-Quantum Traditional Hybrid Schemes |
| |
|
One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. |
| | RFC Formats and Versions |
| |
|
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published. This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. |
| | A YANG Data Model for the RFC 9543 Network Slice Service |
| |
|
This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. |
| |
|
| |
| | RTP over QUIC (RoQ) |
| |
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
|
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. |
| | Definition For New BMP Statistics Type |
| |
|
RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router. This document updates RFC 7854 by adding new statistics type to monitor BMP rib-in and rib- out Ribs. |
| | DLEP Credit-Based Flow Control Messages and Data Items |
| |
|
This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are defined in an extensible and reusable fashion. Their use will be mandated in other documents defining specific DLEP extensions. |
| | Design of the native Cyberspace Map |
| |
|
This memo discusses the design of the native cyberspace map which is stable and flexible to describe cyberspace. Although we have accepted the cyberspace as a parallel new world, we even have not defined its basic coordinate system, which means cyberspace have no its basic space dimension till now. The objective of this draft is to illustrate the basic design methodology of the native coordinate system of cyberspace, and show how to design cyberspace map on this basis. |
| | The Time Zone Information Format (TZif) |
| |
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. |
| | Procedure for Standards Track Documents to Refer Normatively to External Documents |
| |
|
This document specifies a procedure for referencing external standards and specifications from IETF-produced documents on the Standards Track. In doing so, it updates BCP 9 (RFC 2026). |
| | Packet Content Filter for BGP FlowSpec |
| |
|
The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filterer in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address new types of DDoS attack traffic characterized by constant patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes otype, offset value, content-length, and content, encoded in the Flowspec NLRI. This new filter aims to augment DDoS defense capabilities. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with ECDH,ML-KEM,and FrodoKEM |
| |
|
RFC 9370 specifies a framework that supports mulitple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additiona KEMs employed with the oringal ECDH to derive the final shared secret keys for IPsec protocols. The primitive goal is to mitigate the security threat against quantum computers by hybriding additional post-quantum (PQ) KEMs with the orinigal ECDH key exchange. This draft describes concretely how two specific QP KEMs, namely, ML-KEM and FrodoKEM, can be instantiated in the IKEv2 as the additional KEMs with the main ECDH to achieve hybrid key agreement. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, when considering the code points for ML-KEM has been considered in [I-D.D24]. ] |
| | Zeroconf Multicast Address Allocation Problem Statement and Requirements |
| |
|
This document describes a network that requires unique multicast addresses to distribute data. Various challenges are discussed, such as the use of multicast snooping to ensure efficient use of bandwidth, limitations of switch hardware, problems associated with address collisions, and the need to avoid user configuration. After all limitations were considered it was determined that multicast addresses need to be dynamically-assigned by a decentralized, zero- configuration protocol. Requirements and recommendations for suitable protocols are listed and specific considerations for assigning IPv4 and IPv6 addresses are reviewed. The document closes with several solutions that are precluded from consideration. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses |
| |
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a reserved range and prevent collisions by using mDNS to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim- zeroconf-mcast-addr-alloc-ps. |
| |
|
| |
| | H.265 Profile for WebRTC |
| |
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, similar guidance is needed for browsers considering support for the H.265 codec, whose RTP payload format is defined in RFC 7798. |
| | SCION Overview |
| |
|
The Internet has been successful beyond even the most optimistic expectations and is intertwined with many aspects of our society. But although the world-wide communication system guarantees global reachability, the Internet has not primarily been built with security and high availability in mind. The next-generation inter-network architecture SCION (Scalability, Control, and Isolation On Next- generation networks) aims to address these issues. SCION was explicitly designed from the outset to offer security and availability by default. The architecture provides route control, failure isolation, and trust information for end-to-end communication. It also enables multi-path routing between hosts. This document discusses the motivations behind the SCION architecture and gives a high-level overview of its fundamental components, including its authentication model and the setup of the control- and data plane. As SCION is already in production use today, the document concludes with an overview of SCION deployments. For detailed descriptions of SCION's components, refer to [I-D.dekater-scion-pki], [I-D.dekater-scion-controlplane], and [I-D.dekater-scion-dataplane]. A more detailed analysis of relationships and dependencies between components is available in [I-D.rustignoli-scion-components]. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation Information in the DNS. |
| | Sustainability Insights |
| |
| | draft-almprs-sustainability-insights-03.txt |
| | Date: |
07/05/2024 |
| | Authors: |
Per Andersson, Jan Lindblad, Snezana Mitrovic, Marisol Palmero, Esther Roure, Gonzalo Salgueiro, Emile Stephan |
| | Working Group: |
Individual Submissions (none) |
|
Internet and the ICT industry is consuming a sizable portion of the electricity available in the world today, and the fraction has been growing significantly over time. Data shows that the power draw of internet is relatively constant over the day and week, even though the “load” and delivered services vary greatly over this time span. This seems to suggest that there is room for optimizations. This document provides some definitions, some proposed principles for a solution, and then paints a picture of what a solution based on existing standards and some current internet drafts might look like. The first step of an optimization loop is to measure. This document proposes a mechanism to collect energy related telemetry data from the extremely diverse set of devices found in networks today, without necessarily updating the network elements. Once the collection is done, it’s also very relevant to be able to control the devices, and turn them into low power modes when the service demand is lower. |
| | Maintaining Protocols Using Grease and Variability |
| |
|
Long-term interoperability of protocols is an important goal of the network standards process. Deployment success can depend on supporting change, which can include modifying how the protocol is used, extending the protocol, or replacing the protocol. This document presents concepts, considerations, and techniques related to protocol maintenance, such as greasing or variability. The intended audience is protocol designers and implementers. |
| | Power and Energy Efficiency |
| |
| | draft-opsawg-poweff-01.txt |
| | Date: |
07/05/2024 |
| | Authors: |
Jan Lindblad, Snezana Mitrovic, Marisol Palmero, Gonzalo Salgueiro |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a device YANG “dashboard” data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else. |
| | iTip using PARTICIPANT only |
| |
|
This specification specifies updates to RFC5546 iTip which allow scheduling using the PARTICIPANT components specified in RFC9073. New properties are also defined for use within the PARTICIPANT component. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-23.txt |
| | Date: |
07/05/2024 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| | 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. |
| |
|
| |
| | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
| |
|
Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) define protocol messages for X.509v3 certificate creation and management. Both protocol provide interactions between client systems and PKI management entities, such as a Registration Authority (RA) and a Certification Authority (CA). CMP and EST allow an RA/CA to request additional information it has to provide in a certification request. When an end entity places attestation Evidence in a Certificate Signing Request (CSR) it may need to demonstrate freshness of the provided Evidence. Attestation technology today often accomplishes this task via the help of nonces. This document specifies how nonces are provided by an RA/CA to the end entity for inclusion in Evidence. |
| | SRv6 Upper-Layer Checksum |
| |
|
This document defines SRH C-flag and its processing, which makes the IPv6 upper-layer checksum computation rule applicable to both compressed and uncompressed SRv6 SIDs. |
| | Adaptive Forward Erasure Correction for Delay-Sensitive QUIC Connections |
| |
|
This document proposes a FEC supporting mechanism of QUIC protocol for both short flows and long flows protection in accordance to the sender observed packet loss rate. |
| | DNS over IPv6 Best Practices |
| |
|
This document describes an approach to how Domain Name Protocol (DNS) should be carried over IPv6. There have been some operational issues identified in carrying DNS packets over IPv6 and this draft proposes solutions to address them. A summary of what is proposed is to limit IPv6 DNS responses over UDP to be 1280 octets and use TCP or QUIC for anything larger. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-09.txt |
| | Date: |
06/05/2024 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang |
| | 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. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| |
|
| |
| | Optimizing BFD Authentication |
| |
|
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880. |
| | Matroska Media Container Codec Specifications |
| |
| | draft-ietf-cellar-codec-13.txt |
| | Date: |
05/05/2024 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block Element and in an optional CodecPrivate Element. |
| | Matroska Media Container Tag Specifications |
| |
| | draft-ietf-cellar-tags-13.txt |
| | Date: |
05/05/2024 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska tags, namely the tag names and their respective semantic meaning. |
| | Deprecation of AS_SET and AS_CONFED_SET in BGP |
| |
|
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it proscribes the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (type 1) and also updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (type 4) AS_PATH segments. Finally, it obsoletes RFC 6472. |
| | Multiple Algorithm Rules in DNSSEC |
| |
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. |
| | Mitigating QNAME minimization performance problems |
| |
|
QNAME minimization improves DNS privacy by truncating query names sent to authoritative name servers. While it works well when there is a zone cut between each label in a name, when a zone includes more than one level of labels, it can cause multiple redundant queries to the same server, significantly increasing the load on that server without additional privacy benefits. This document describes some situations where minimization causes load problems and potential ways to fix the problem, |
| |
|
| |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
| |
| | draft-ietf-lamps-x509-slhdsa-00.txt |
| | Date: |
03/05/2024 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-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. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 205 Stateless Hash-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | 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) architecture and protocols. 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. |
| | OAuth 2.0 Protected Resource Metadata |
| |
|
This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. |
| | Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) |
| |
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). It is an improved alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and partial replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an improved alternative to RFC 6083 and removes the 16 kbytes limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of security fixes and improvements. It updates the DTLS versions and SCTP-AUTH HMAC algorithms to use. It mitigates reflection attacks of data and control chunks and replay attacks of data chunks. It simplifies secure implementation by some stricter requirements on the establishment procedures as well as rekeying to align with zero trust principles. |
| | WebRTC-HTTP ingestion protocol (WHIP) |
| |
| | draft-ietf-wish-whip-14.txt |
| | Date: |
03/05/2024 |
| | Authors: |
Sergio Murillo, Alex Gouaillard |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This document updates RFC 8842 and RFC 8840. |
| |
|
| |
| | BGP MPLS-Based Ethernet VPN |
| |
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates RFC8214 (Virtual Private Wire Service Support in Ethernet VPN). |
| | Conveying Transceiver-Related Information within RSVP-TE Signaling |
| |
|
The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. |
| | IKEv2 support for per-resource Child SAs |
| |
|
This document defines one Notify Message Status Types and one Notify Message Error Types payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child Security Associations (SAs) with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection. |
| | TLD Zone Pipeline: Requirements And Design Principles |
| |
|
Today most TLD registries publish DNSSEC signed zones. The sequence of steps from generating the unsigned zone, via DNSSEC signing and various types of verification is referred to as the "zone pipeline". The robustness and correctness of the zone pipeline is of crucial importance and the zone pipeline is one of the most critical parts of the operations of a TLD registry. The goal of this document is to describe the requirements that the .SE Registry choose in preparation for the implementation of a new zone pipeline. The document also describes some of the design consequences that follow from the requirements. Hence this document is intended to work as a guide for understanding the actual implementation, which is planned to be released as open source. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-tld-zone-pipeline (https://github.com/johanix/draft-johani-tld-zone-pipeline). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. |