| |
|
| |
| | 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. |
| | 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. |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-08.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-07.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
| |
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, which we call timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | IGP Color-Aware Routing |
| |
| | draft-lin-lsr-igp-car-02.txt |
| | Date: |
27/11/2024 |
| | Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| | 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. |
| | User Discovery Requirements |
| |
|
This document defines requirements for the user discovery problem within the More Instant Messaging Interoperability (MIMI) working group. User discovery is essential for interoperability, allowing message senders to locate recipients across diverse platforms using globally unique, cross-service identifiers (e.g., email addresses, phone numbers). The core challenge involves reliably mapping these identifiers to messaging service providers and determining the reachability of a recipient's identifier across multiple providers. |
| | Satellite Ground Routing Architecture Based on Access Satellite Prediction |
| |
|
With the development of network technology, the satellite network are gradually integrating with the terrestrial network. This draft illustrates a satellite ground routing architecture based on access satellite prediction to solve the end-to-end communication issue in the satellite ground integration scenario where the connection between terrestrial nodes and satellites switches frequently. This architecture includes registration nodes which are responsible for maintaining access node information. Each access node preserve satellite orbit information, performs access satellite prediction, and generates encapsulation addresses. The access satellite undertakes data encapsulation, data forwarding, and data unencapsulation based on encapsulation addresses. |
| | Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces |
| |
|
This document discusses current limitations in IPv6 Stateless Address Auto-cofiguration (SLAAC) that prevent support for common multi- router and multi-interface scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. |
| | Support for Multi-Router and Multi-Prefix IPv6 Networks |
| |
|
This document specifies IPv6 host behavior to improve their support for general and common multi-router and multi-prefix scenarios. It formally updates RFC 4861, RFC 4862, and RFC 8028 such that such scenarios are properly supported. This document also formally updates RFC 8504, thus requiring support for multi-router and multi- prefix scenarios in all IPv6 nodes. |
| | Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects |
| |
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. |
| | 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. |
| |
|
| |
| | 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. |
| | Generic Address Assignment Option for 6LowPAN Neighbor Discovery |
| |
| | draft-ietf-6lo-nd-gaao-01.txt |
| | Date: |
25/11/2024 |
| | Authors: |
Luigi Iannone, Zhe Lou, Adnan Rashid |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks, enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to algorithmically assign addresses and prefixes to nodes in a 6LowPAN deployment. |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-05.txt |
| | Date: |
25/11/2024 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Extended Communities Derived from Route Targets |
| |
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. |
| | A SAVI Solution for WLAN |
| |
|
This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. |
| | RFC 3535,20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling |
| |
|
The IAB organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. |
| | Path Tracing in SRv6 networks |
| |
| | draft-filsfils-ippm-path-tracing-02.txt |
| | Date: |
25/11/2024 |
| | Authors: |
Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija |
| | Working Group: |
Individual Submissions (none) |
|
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 egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. |
| | 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. This document serves to outline the problem statement for current route origin registry. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
This document specifies how the post-quantum signature scheme ML-DSA [FIPS204], in combination with traditional algorithms RSA- PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for authentication in TLS 1.3. The composite ML-DSA approach is beneficial in deployments where operators seek additional protection against potential breaks or catastrophic bugs in ML-DSA. |
| | Scalable Quality Extension for the Opus Codec |
| |
|
This document updates RFC6716 to add support for a scalable quality layer. |
| | Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. |
| |
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor- specific information in stateful PCE operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor-specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in stateless PCE Communication Protocol (PCEP) messages. This document extends this capability for the Stateful PCEP messages. This document updates RFC 7470 to revise the reference to the IANA registry for managing Enterprise Numbers. |
| | RDAP RIR Search |
| |
|
The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various IP and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. |
| | Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document explores the applicability of Bidirectional Forwarding Detection (BFD) in multipoint networks to enable sub-second convergence in the Virtual Router Redundancy Protocol (VRRP) for determining the Active Router. Additionally, it defines extensions to bootstrap point-to-multipoint BFD sessions using an IPv4/IPv6 VRRP Advertisement message, and, thus, updates RFC 9568. |
| | Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6) |
| |
|
This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages. |
| |
|
| |
| | The OPAQUE Augmented PAKE Protocol |
| |
| | draft-irtf-cfrg-opaque-18.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | DTN Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-02.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Daniel Migault, Tobias Guggemos, David Schinazi, J. Atwood, Daiying Liu, Stere Preda, Maryam Hatami, Sandra Cespedes |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rules Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security |
| |
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekey operations. This draft updates RFC8784 by extending use of PPKs. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | An Architecture for More Instant Messaging Interoperability (MIMI) |
| |
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. |
| | Reporting of Errors via LAYOUTRETURN in NFSv4.2 |
| |
|
The Parallel Network File System (pNFS) allows for a file's metadata (MDS) and data (DS) to be on different servers. When the metadata server is restarted, the client can still modify the data file component. During the recovery phase of startup, the metadata server and the data servers work together to recover state (which files are open, last modification time, size, etc.). If the client has not encountered errors with the data files, then the state can be recovered, avoiding resilvering of the data files. With any errors, there is no means by which the client can report errors to the metadata server. As such, the metadata server has to assume that file needs resilvering. This document presents an extension to RFC8435 to allow the client to update the metadata and avoid the resilvering. |
| | An EAT-based Key Attestation Token |
| |
| | draft-bft-rats-kat-05.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Mathias Brossard, Thomas Fossati, Hannes Tschofenig, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. |
| | The "doi" URI Scheme |
| |
|
This I-D series was initially used to specify the "doi" URI scheme. This specification has since been replaced by [doi-uri-scheme]. |
| | CATS Metrics Definition |
| |
|
This document defines a set of computing metrics used for Computing- Aware Traffic Steering(CATS). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Computing-Aware Traffic Steering Working Group mailing list (cats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cats/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-cats-metric-definition. |
| | Conceptual Model for Digitized Emblems |
| |
|
This document describes the conceptual models of use for digital emblems. |
| | ICMP Extension Header Length Field |
| |
|
The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | The Contextualized REST Architecture |
| |
|
The REST architecture is extremely popular in modern computing environments. A benefit it provides is that each request can be serviced by independent server side components such as different instances of web servers or different instances of serverless request handlers. The lack of any context associated with a request means that the client has to provide the entire context with every request. In monolithic server-side architectures the client typically only provides an identifier to a previously established "session" on the server side, which is retrieved from a persistent storage such as a database. However, this strategy often does not work in microservices architectures, where the persistent storage may be many hops away from the server-side components that handle the incoming REST API requests. As a result, REST APIs are used between services and each request is required to carry large context including tokens such as Transaction Tokens [TRATS] (which assure the identity and context of each request), SPIFFE [SPIFFE] tokens (which assures the service identity) and possibly other context. The Contextualized REST (CREST) architecture adds a cached context to REST, with mechanisms to negotiate the establishment of the context when it is not found. Each request can refer to the context items it depends upon instead of carrying the entire context with the request. The server can accept the reference to the context item or respond with a specific error to prompt the client to reestablish the context. Clients can create new or delete existing context items in separate requests or as a part of other requests. The CREST architecture assumes the server holds the context across different requests in a server-side cache. Such a cache may be typically shared across various applications and services within a VPC or a data center. The possibility that subsequent requests from the same client will reach different VPCs or data centers is low, thus providing an efficiency optimization for the vast majority of requests. |
| | Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. |
| | YANG Data Model for SRv6 Base and Static |
| |
| | draft-ietf-spring-srv6-yang-04.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Syed Raza, Sonal Agarwal, Xufeng Liu, Zhibo Hu, Iftekhar Hussain, Himanshu Shah, Dan Voyer, Hani Elmalky, Satoru Matsushima, Katsuhiro Horiba, Jaganbabu Rajamanickam, Ahmed Abdelsalam |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| |
|
| |
| | 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. |
| | The DRIP DET public Key Infrastructure |
| |
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. |
| | Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol |
| |
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. |
| | Considerations of network/system for AI services |
| |
| | draft-irtf-nmrg-ai-deploy-00.txt |
| | Date: |
15/11/2024 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Ho-Sun Yoon, Pedro Martinez-Julia |
| | Working Group: |
Network Management (nmrg) |
|
As the development of AI technology matured and AI technology began to be applied in various fields, AI technology is changed from running only on very high-performance servers with small hardware, including microcontrollers, low-performance CPUs and AI chipsets. In this document, we consider how to configure the network and the system in terms of AI inference service to provide AI service in a distributed method. Also, we describe the points to be considered in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying network-based AI services, such as self-driving vehicles and network digital twins, are described. |
| | 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 defines the format for the Extended IP Filters for Flow Specification FSv2. |
| | Controlling IP Fragmentation on Common Platforms |
| |
|
When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. |
| | PSI based on ECDH |
| |
| | draft-wang-ppm-ecdh-psi-00.txt |
| | Date: |
15/11/2024 |
| | Authors: |
wangyuchen, Wenting, Yufei Lu, Cheng Hong, Jin Peng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Elliptic Curve Diffie-Hellman Private Set Intersection (ECDH-PSI). It instantiates the classical Meadows match-making protocol with standard elliptic curves and hash-to-curve methods. In ECDH-PSI, data items are encoded to points on an elliptic curve, and masked by the private keys of both parties. After collecting the mutually masked datasets from both parties, a participant computes their intersection and outputs the corresponding original data items as result. |
| | Use of ML-DSA in TLS 1.3 |
| |
|
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/tls-mldsa. |
| | Use of SLH-DSA in TLS 1.3 |
| |
| | draft-reddy-tls-slhdsa-00.txt |
| | Date: |
15/11/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. |
| | ECDP: Elliptic Curve Data Protocol |
| |
|
This document specifies the Elliptic Curve Data Protocol (ECDP), a peer-to-peer (P2P) communication protocol tailored for decentralized networks. ECDP utilizes elliptic curve cryptography (ECC) for encryption, employs the Elliptic Curve Digital Signature Algorithm (ECDSA) for message authentication, and leverages the Diffie-Hellman key exchange using elliptic curves for secure session initialization. The protocol supports a variety of elliptic curves (e.g., secp256k1, secp384r1) with varying key sizes, and is designed to operate over both TCP and UDP. Additionally, it utilizes SHA-256 or SHA-512 for cryptographic hash verification to ensure message integrity. |
| | The OAuth 2.1 Authorization Framework |
| |
| | draft-ietf-oauth-v2-1-12.txt |
| | Date: |
15/11/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. |
| | Selective Disclosure for JWTs (SD-JWT) |
| |
|
This specification defines a mechanism for the selective disclosure of individual elements of a JSON-encoded data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-11.txt |
| | Date: |
15/11/2024 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines the RATS conceptual message wrapper (CMW) format, a type of encapsulation format that can be used for any RATS messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. Additionally, the document describes a collection type that enables the aggregation of one or more CMWs into a single message. This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols. In addition, a Media Type and a CoAP Content-Format are defined for transporting CMWs in HTTP, MIME, CoAP and other Internet protocols. |
| | Discouraging use of RFC7050 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis |
| |
|
RFC7050 describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation (RFC7915). This methodology depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". Because newer methods exist that lack the requirement of a higher level protocol, instead using existing operations in the form of native router advertisements, discovery of the IPv6 prefix used for protocol translation using RFC7050 should be discouraged. RFC7050 MAY only be used if other methods (such as RFC8781]) can not be used. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge |
| |
| | draft-ietf-acme-dns-account-label-00.txt |
| | Date: |
13/11/2024 |
| | Authors: |
Antonios Chariton, Amir Omidi, James Kasten, Fotis Loukos, Stanislaw Janikowski |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. By adding a unique label to the DNS validation record name, the dns-account-01 challenge avoids CNAME delegation conflicts inherent to the dns-01 challenge type. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. |
| | IMAP Support for UTF-8 |
| |
| | draft-ietf-extra-6855bis-04.txt |
| | Date: |
13/11/2024 |
| | Authors: |
Pete Resnick, Jiankang Yao, Arnt Gulbrandsen |
| | Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
This specification extends the Internet Message Access Protocol (IMAP4rev1, RFC 3501) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 [RFC9051], since that protocol includes everything in this extension. |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-05.txt |
| | Date: |
13/11/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. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. |
| | EVPN Anycast Multi-Homing |
| |
|
The current Ethernet Virtual Private Network (EVPN) all-active multi- homing procedures in Network Virtualization Over Layer-3 (NVO3) networks provide the required Split Horizon filtering, Designated Forwarder Election and Aliasing functions that the network needs in order to handle the traffic to and from the multi-homed CE in an efficient way. In particular, the Aliasing function addresses the load balancing of unicast packets from remote Network Virtualization Edge (NVE) devices to the NVEs that are multi-homed to the same CE, irrespective of the learning of the CE's MAC/IP information on the NVEs. This document describes an optional optimization of the EVPN multi-homing Aliasing function - EVPN Anycast Multi-homing - that is specific to the use of EVPN with NVO3 tunnels (i.e., IP tunnels) and, in typical Data Center designs, may provide some benefits that are discussed in the document. |
| | Reliability Framework for SRv6 Service Function Chaining |
| |
|
This document describes the framework for protection of service function chains in source routing networks. |
| | A Template for IANA Cryptographic Registries |
| |
|
This document provides recommendations for how IETF Working Groups should create IANA registries that are related to cryptographic algorithms. It is based on the lessons learned from the TLS registries over the years. |
| | Hybrid Signature Considerations |
| |
|
This document discusses how and when to use hybrid post-quantum/ traditional signatures, and when not to, including prehashing and key use. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-10.txt |
| | Date: |
13/11/2024 |
| | Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on any Transparency Service, with the guarantee that any Relying Parties will be able to verify them. |
| |
|
| |
| | Deprecation Of The IPv6 Router Alert Option |
| |
|
This document deprecates the IPv6 Router Alert Option. Protocols that use the Router Alert Option may continue to do so, even in future versions. However, protocols that are standardized in the future must not use the Router Alert Option. This document obsoletes RFC 2711. |
| | The IPv6 VPN Service Destination Option |
| |
|
This document describes an experiment in which VPN service information for both layer 2 and layer 3 VPNs is encoded in a new IPv6 Destination Option. The new IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment. |
| | BIER Ping and Trace |
| |
| | draft-ietf-bier-ping-15.txt |
| | Date: |
08/11/2024 |
| | Authors: |
Nagendra Nainar, Carlos Pignataro, Mach Chen, Greg Mirsky |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast-related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. |
| | Intimate Partner Violence Digital Considerations |
| |
| | draft-irtf-hrpc-ipvc-01.txt |
| | Date: |
08/11/2024 |
| | Authors: |
Sofia Celi, Juliana Guerra, Mallory Knodel |
| | Working Group: |
Human Rights Protocol Considerations (hrpc) |
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These security compromises go beyond active and passive on-path attacks [RFC7624]. With a focus on protocols, the document describes tactics of the IPV attacker and potential counter-measures. |
| | 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. |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | Encapsulation of BFD for SRv6 Policy |
| |
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. |
| | BGP Extension for Distributing CP Threshold Constraints of SR Policy |
| |
|
This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. |
| | YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
| |
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| | BGP Flowspec for Computing-Aware Traffic Steering |
| |
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework, This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. |
| | Distribute Service Metric by BGP |
| |
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
| |
| | draft-ietf-spring-stamp-srpm-17.txt |
| | Date: |
08/11/2024 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-27.txt |
| | Date: |
08/11/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.] |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension |
| |
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". |
| | Secure EVPN |
| |
| | draft-ietf-bess-secure-evpn-02.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Ali Sajassi, Ayan Banerjee, Samir Thoria, David Carrel, Brian Weis, John Drake |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The applications of EVPN-based solutions (BGP MPLS-based Ethernet VPN and Network Virtualization Overlay Solution using EVPN) have become pervasive in Data Center, Service Provider, and Enterprise segments. It is being used for fabric overlays and inter-site connectivity in the Data Center market segment, for Layer-2, Layer-3, and IRB VPN services in the Service Provider market segment, and for fabric overlay and WAN connectivity in Enterprise networks. For Data Center and Enterprise applications, there is a need to provide inter-site and WAN connectivity over public Internet in a secured manner with same level of privacy, integrity, and authentication for tenant's traffic as IPsec tunneling using IKEv2. This document presents a solution where BGP point-to-multipoint signaling is leveraged for key and policy exchange among PE devices to create private pair-wise IPsec Security Associations without IKEv2 point-to-point signaling or any other direct peer-to-peer session establishment messages. |
| | Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer |
| |
| | draft-ietf-bier-pmmm-oam-16.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Greg Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. |
| | A YANG Data Model for Optical Transport Network Topology |
| |
| | draft-ietf-ccamp-otn-topo-yang-20.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. |
| | TLS Extension for DANE Client Identity |
| |
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. |
| | Bundle Protocol Endpoint ID Patterns |
| |
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| | Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 |
| |
| | draft-ietf-dtn-udpcl-00.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Brian Sipos, Joshua Deaton |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of RFC7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unreliable transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. |
| | Segment Routing Segment Types Extensions for BGP SR Policy |
| |
|
This document specifies the signaling of additional Segment Routing Segment Types for signaling of Segment Routing (SR) Policies in BGP using SR Policy Subsequent Address Family Identifier. |
| | Advertising Segment Routing Policies in BGP |
| |
| | draft-ietf-idr-sr-policy-safi-10.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain |
| | Working Group: |
Inter-Domain Routing (idr) |
|
A Segment Routing (SR) Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI to advertise a candidate path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-10.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | Abstract |
| |
|
This document introduces the Shang Mi(SM) cryptographic algorithm for openpgp protocol. |
| | Abstract |
| |
|
This document describes how to use a newly added message digest algorithm "SM3" in the TSIG protocol. It can be used to calculate the digest for the TSIG key by using a hash function. This document details the supplementation of the SM3 algorithm in TSIG. |
| | ESP Echo Protocol |
| |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a symmetric digital identity authentication system that requires no federation of authentication domains. The main components of the authentication process between two entities are: 1. *Symmetric authentication protocol* - Both entities must recognize each other and are authenticated by their identity provider according to a symmetric message exchange scheme. It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - A special network dedicated to creating a protected environment for exchanging authentication messages between Identity Providers (IdPs) constitutes the infrastructure to avoid domain federation. 3. *Custodian concept* - IdPs are divided into two typologies to better protect personal data and link digital identity to physical one. A generic IdP (called trustee) to manage digital authentication only and a specific IdP (called custodian), with the legal right to process the individual's real data and under the control of country's authority, to manage the physical identity and the link with the digital one. |
| | SLAAC Prefixes with Variable Interface ID (IID) Problem Statement |
| |
|
In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. |
| | SLAAC Prefixes with Variable Interface ID (IID) |
| |
|
This draft proposes the use of a longer prefixes in PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits. This would eliminate the race to the bottom concerns. This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. |
| | SRv6 Inter Domain Routing |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | OpenID Connect standard claims registration for CBOR Web Tokens |
| |
|
This document registers OpenId Connect standards claims already used in JSON Web Tokens for CBOR Web Tokens. |
| | BGP Route Type Capability |
| |
|
BGP supports different route types, which define the encoding of Network Layer Reachability Information (NLRI) for some of the Address Family Identifier (AFI)/Subsequent Address Family Identifier (SAFI), like Ethernet VPN (EVPN), Multicast VPN(MVPN) and so on. BGP speaker MAY reset the BGP session if a given route type in an NLRI is not supported instead of treat-as-withdraw. This document defines Optional Capabilities pertaining to the exchange of route types that are supported for a particular AFI and SAFI. This framework facilitates the maintenance of sessions without necessitating resets or the inadvertent dropping of updates. |
| | SRv6 Inter Domain Routing Architecture |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | Two DNS Resolver Information Keys for DNSSEC and DNS64 |
| |
|
This document specifies two DNS Resolver Information Keys (RFC 9606) for DNSSEC validation capability, "dnssecval" and DNS64 synthesis, "dns64". |
| | Attester Issuer Protocol |
| |
|
TODO Abstract About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://smhendrickson.github.io/draft-hendrickson-pp-attesterissuer/ draft-hendrickson-pp-attesterissuer.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- hendrickson-pp-attesterissuer/. Source for this draft and an issue tracker can be found at https://github.com/smhendrickson/draft-hendrickson-pp-attesterissuer. |
| | OpenPGP Signatures and Signed Messages |
| |
|
This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| | A Common YANG Data Model for Attachment Circuits |
| |
| | draft-ietf-opsawg-teas-common-ac-13.txt |
| | Date: |
07/11/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. |
| | 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. |
| | 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). |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document draws on several years of operational experience to update RFC 6724, defining the concept of "known-local" ULA prefixes that enable ULA-to-ULA communications within fd00::/8 to become preferred over both IPv4-IPv4 and GUA-to-GUA for local use. The document defines the means by which nodes can both identify and insert such prefixes into their address selection policy table. It also clarifies the mandatory, unconditional requirement for support for Rule 5.5 and demotes the preference for 6to4 addresses. These changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios, and makes preference for IPv6 over IPv4 consistent in local site networks for both ULA and GUA prefixes. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-11.txt |
| | Date: |
06/11/2024 |
| | Authors: |
Rishabh Parekh, Clarence Filsfils, Mankamana Mishra, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | Hedged ECDSA and EdDSA Signatures |
| |
|
Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. |
| | DTNMA Asynchronous Management Protocol (AMP) |
| |
| | draft-ietf-dtn-amp-00.txt |
| | Date: |
06/11/2024 |
| | Authors: |
Edward Birrane, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport mapping for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management of resource constrained devices and over challenged networks. |
| | API Keys and Privacy |
| |
|
Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. |
| | Clarification and enhancement of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-13.txt |
| | Date: |
06/11/2024 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. Moreover, it provides new convenient and straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows specifying a subject Distinguished Name (DN). |
| | CoRE Resource Directory Extensions |
| |
|
A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. |
| | Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS) |
| |
|
BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement. |
| | 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. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. |
| | Requirements for Energy Efficiency Management |
| |
|
This document delineates the requirements for standards specifications in Energy Efficiency Management, extending the foundational work of RFC6988 and incorporating recent insights from operator requirements and the GREEN BoF discussions. Eleven years after the publication of RFC6988, this document reassesses and updates the requirements to align with contemporary needs. The primary objectives of this draft, which are listed in the goals and scope with the creation of the GREEN WG charter, is focusing on two main targets: (1) collecting and updating requirements for the management of energy-efficient networks, and (2) defining use cases for managing energy-efficient networks. This draft merges the drafts [rfc6988bis-green] and [green-bof-reqs]. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-stephan-green-terms-ucs-and-reqs |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. |
| | OAuth 2.0 Client ID Scheme |
| |
|
This specification defines the concept of a Client Identifier Scheme to enable Authorization Servers and Clients to use more than one mechanism to obtain and validate Client metadata. |
| | Robots.txt update proposal |
| |
|
This document proposes updates to the robots.txt standard to accommodate AI-specific crawlers, introducing a syntax for user-agent identification and policy differentiation. It aims to enhance the management of web content access by AI systems, distinguishing between training and inference activities. |
| | NTP Interleaved Modes |
| |
|
This document specifies interleaved modes for the Network Time Protocol (NTP), which improve the accuracy of time synchronization by enabling use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes. |
| | The PrivateToken HTTP Authentication Scheme Extensions Parameter |
| |
|
This document specifies new parameters for the "PrivateToken" HTTP authentication scheme. This purpose of these parameters is to negotiate and carry extensions for Privacy Pass protocols that support public metadata. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. To avoid YANG non-backward compatible change restrictions, the YANG module will have desigination ietf-vrrp-2.yang rather than ietf-vrrp.yang. This document obsoletes RFC 8347. |
| |
|
| |
| | Comparison of CoAP Security Protocols |
| |
|
This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for network inventory. The scope of this base model is set to be application- and technology-agnostic. However, the data model is designed with appropriate provisions to ease future augmentations with application- specific and technology-specific details. |
| | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
| |
|
When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) |
| | DLEP Radio Quality Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. |
| | DLEP Radio Band Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the frequency bands used by the radio. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| | Erasure Encoding of Files in NFSv4.2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Version 2 Layout Type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data replication is also added to provide integrity. |
| | Applicability of TVR YANG Data Models for Scheduling of Network Resources |
| |
|
Time-Variant Routing (TVR) is a routing system that can support the predicted topology changes caused by internal or external reasons. Typical use cases include mobility networks with moving nodes, resource constraints such as power, and tidal traffic demand networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why, and it outlines operational and security considerations when deploying TVR-based technologies. |
| | Extensions for DNS Public Resolvers |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. |
| | SPICE Traceability CWT Claims |
| |
|
This document proposes additional claims for CBOR Web Tokens (CWT) to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims aim to standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. |
| | DNS Servers MUST Shuffle Answers |
| |
|
DNS Resource Records (DNS RR) are often used in the order that they are returned. This means that if there are more than one RR in a RR set, then they should be returned in a random order, to reduce bias in how the answers are used. |
| | Palimpsest |
| |
|
This document provides an overview of the Palimpsest structured collaboration system. Palimpsest facilitates review of documents through reactions tagged with weak semantics defining processing steps for the reaction. Documents are grouped into projects with a common set of allowed semantic moves and processing steps. This allows the revie |
| | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
|
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT Nodes". Each DDT Node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT Nodes to which more-specific EID-prefixes are delegated. This document obsoletes RFC 8111. |
| | Procedure for YANG SID Allocation |
| |
|
This document defines a standardized procedure for the allocation of YANG SID Ranges (YANG Schema Item iDentifier ranges) and the subsequent assignment of SIDs for IETF RFCs with YANG files. |
| | SID Space (5f00::/16) Inter-domain Addressing Recommendations |
| |
|
This specification recommends a specific structured use of the SRv6 SIDs prefix in support of Inter-Domain SRv6 networks. The core of the proposal is to structure the address space by Autonomous System Number (ASN). Use of this proposed structure is entirely voluntary. Voluntary use of this structure aids SRv6 operations while preserving the ability to use this prefix across cooperating SRv6 domains, but not across the general Internet. |
| | Making BMP fruible offline |
| |
|
BMP (BGP Monitoring Protocol) [RFC7854] is perfectly suited for real- time consumption but less ideal for off-wire historical purposes. The main issue is the dependence that parsing BGP Update PDUs has on knowing which capabilities have been agreed when establishing the BGP session with the peers, which could have happened long time ago (days, weeks, months). This document defines a new optional BMP message type, called Peer Summary, that carries a summary of the established BGP sessions along with their capabilities and that is intended to be injected in the BMP feed at configurable time intervals and/or ad-hoc whenever it is felt necessary to improve fruition of BMP data offline. |
| | Computing Resource Authenticity Evaluation in Computing-Aware Traffic Steering |
| |
|
This draft introduces an evaluation scheme for computing resource authenticity. The scheme aims to verify and evaluate the authenticity of computing resources in the network using application layer method. This draft describes the basic principle of the scheme and authentication mechanism. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-06.txt |
| | Date: |
05/11/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 (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-10.txt |
| | Date: |
05/11/2024 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, Mankamana Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments. A SR Point-to-Multipoint (SR P2MP) Policy defines a P2MP tree and a PCE computes and instantiates the tree. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | Short-Lived Certificates for Secure Telephone Identity |
| |
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-20.txt |
| | Date: |
05/11/2024 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. |
| |
|
| |
| | Simple Public Key Infrastructure (SPKI) S-Expressions |
| |
| | draft-rivest-sexp-12.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Ronald Rivest, Donald Eastlake |
| | Working Group: |
Applications and Real-Time Area (art) |
|
This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI, RFC 2692) certificates with the intent that it be more widely applicable. It has been and is being used elsewhere. There are multiple implementations in a variety of programming languages. Uses of this representation are referred to in this document as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: it gives a "canonical form" for them, describes two "transport" representations, and also describe an "advanced" format for display to people. |
| | EVPN Support for L3 Fast Convergence and Aliasing/Backup Path |
| |
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. |
| | Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. |
| | Considerations for Benchmarking Network Performance in Containerized Infrastructures |
| |
|
Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resources allocation and network technologies are specified for containerized network functions. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. |
| | IAB AI-CONTROL Workshop Report |
| |
|
The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work. |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
| |
|
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also described. |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA |
| |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-20.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. |
| | LISP L2/L3 EID Mobility Using a Unified Control Plane |
| |
| | draft-ietf-lisp-eid-mobility-15.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | DLEP Radio Channel Utilization Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | The VERBATIM Digest Algorithm for DS records |
| |
|
The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Juniper's Secure Vector Routing (SVR) |
| |
| | draft-menon-svr-07.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Abilash Menon, Patrick MeLampy, Michael Baj, Patrick Timmons, Hadriel Kaplan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Juniper's Secure Vector Routing (SVR). SVR is an overlay inter-networking protocol that operates at the session layer. SVR provides end-to-end communication of network requirements not possible or practical using network headers. SVR uses application layer cookies that eliminate the need to create and maintain non-overlapping address spaces necessary to manage network routing requirements. SVR is an overlay networking protocol that works through middleboxes and address translators including those existing between private networks, the IPv4 public internet, and the IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases and improves security at the networking routing plane. SVR eliminates the need for encapsulation and decapsulation often used to create non-overlapping address spaces. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| | draft-sajassi-bess-rfc8317bis-03.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Ali Sajassi, Jorge Rabadan, John Drake, Arivudainambi Gounder, Aaron Bamberger |
| | Working Group: |
Individual Submissions (none) |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC7796, "Ethernet- Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC7385; hence, it updates RFC7385 accordingly. This document obsoletes RFC8317. |
| | BGP Route Broker for Hyperscale SDN |
| |
|
This document describes an optimized mechanism for BGP route reflection, known as BGP route broker. It aims to utilize the BGP- based IP VPN as an overlay routing protocol in a scalable manner, specifically for hyperscale data center network virtualization environments, commonly referred to as Software-Defined Network (SDN) environments. |
| | Route Target ORF |
| |
|
This document defines a new Outbound Router Filter (ORF) type for BGP, referred to as "Route Target Outbound Route Filter", that can be used to perform route target based route filtering. |
| | SRH Reduction for SRv6 End.M.GTP6.E Behavior |
| |
|
Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. |
| | A Mechanism for X.509 Certificate Discovery |
| |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. |
| | Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. |
| | Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
| |
|
The document [I-D.draft-mhkk-dmm-mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an IPv6 dataplane routing information. When there are multiple candidate instances located at different location to serve an user request, the MUP Provider Edge (PE) might prioritize the closest service location. However, the closest routing path might not be the optimal route. This document discusses how the mentioned MUP architecture can be leveraged to set up dataplane routing paths to the optimal service instance location with the assistance of computing-aware traffic steering capabilities. For each session request, based on the up-to- date collected computing and network information, the MUP controller can convert the session information to the optimal route. |
| | Securing hybrid network - criteria and requirements |
| |
|
This document analyzes requirements for ensuring and monitoring the security status of the network used under complex network environment such as hybrid cloud or mixed cloud settings. |
| | 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. |
| | Hosting Encrypted DNS Forwarders on CPEs |
| |
|
Typical connectivity service offerings based upon on Customer Premise Equipment (CPEs) involve DNS forwarders on the CPE for various reasons (offer local services, control the scope/content of information in DNS, ensure better dependability for local service, provide control to users, etc.). Upgrading DNS to use encrypted transports introduces deployment complications as to how to sustain current offerings with local services. Solutions are needed to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. This document describes the problem and to what extent existing solutions can or can't be used for these deployments. For example, Star certificates and name constraints extension suffer from the problem of deploying a new feature to CAs, TLS clients, and servers. |
| | Applicability of Computing-Aware Traffic Steering to Intelligent Transportation Systems |
| |
|
This document describes the applicability of Computing-Aware Traffic Steering (CATS) to Intelligent Transportation Systems (ITS). CATS provides the steering of packets of a traffic flow for a specific service request toward the corresponding service instance at an edge computing server at a service site. CATS are applicable for Computing-Aware ITS including (i) Context-Aware Navigation Protocol (CNP) for Terrestrial Vehicles and Unmanned Aerial Vehicles (UAV), (ii) Edge-Assisted Cluster-Based MAC Protocol (ECMAC) for Software- Defined Vehicles, and (iii) Self-Adaptive Interactive Navigation Tool (SAINT) for Cloud-Based Navigation Services, and (iv) Cloud-Based Drone Navigation (CBDN) for Efficient Drone Battery Charging. |
| | Publishing End-Site Prefix Lengths |
| |
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
Path Computation Element Communication Protocol (PCEP) is a protocol defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various LSP identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs * A fallback to Binding label/Segment Identifier (SID) allocation by |
| | Generalized RPSL External Reference |
| |
|
The Routing Policy Specification Language (RPSL), which has operationally evolved since it was standardized in 1999, has recently added a geofeed: attribute to the innet[6]num: class to reference data external to RPSL. There is now a proposal add another attribute referencing external data, prefixlen:. This document describes a more general and extensible mechanism for external references. It also tries to anticipate the RIRs evolving from RPSL to Registration Data Access Protocol (RDAP). |
| | Dynamic Network Adjustments for Cloud Service Scaling |
| |
|
This document specifies a framework for dynamically adjusting network configurations in response to cloud service scaling events. As cloud services grow, increase traffic, or add resources, automatically adapting network configurations can improve performance and enable greater interoperability. Manual network adjustments are often slow, error-prone, and inadequate for the rapid changes of cloud services. The proposed framework, along with the associated YANG models, facilitates seamless interoperability among network controllers and equipment from various vendors, which is an essential requirement for Telecom Cloud providers operating in multi-vendor environments. |
| | SRv6 Deployment Options |
| |
|
This document presents various options to help provide deployment direction to those whose networks will be upgraded to an SRv6 environment. Whether the existing network is IPv4, IPv6, MPLS, SR- MPLS or other, this draft provides direction on how to seemlessly upgrade to SRv6. |
| | Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | BGP SRv6 Policy SID List Optimization |
| |
|
In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a BGP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy. |
| | VCON for MIMI Messages |
| |
|
This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (MIMI) content format. |
| | SCONE Video Optimization Requirements |
| |
|
These are the requirements for the "Video Optimization" use-case for SCONE, 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. 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/mjoras/sadcdn-video-optimization-requirements. |
| | Future Research Directions on Energy-Aware Security Mechanisms |
| |
|
With the onset of the climate emergency, all areas of human activity are expected to continuously assess their Greenhouse Gas emissions and encourage the use of clean energy sources as much as possible. The current discussion on green networking in the Network Management research field still needs to be expanded to the adjoined areas, such as Network Security. This document summarizes the security considerations of the existing works and outlines possible research directions for energy-aware security mechanisms. |
| | SRv6 Inter Domain Routing Use Cases |
| |
|
This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and seamlessly stitching the overlays across inter domain boundaries. This draft analyzes the SRv6 Design and Operational considerations regarding SRv6 Inter Domain routing and the SRv6 forwarding plane. This draft also describes three real world use cases of SRv6 Compression Next CSID and operational considrations with regards to SRv6 inter domain routing. |
| | HTTP Version Translation of the Capsule Protocol |
| |
|
This draft specifies how HTTP intermediaries can translate the Capsule Protocol between HTTP versions. 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-kb-capsule-conversion/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/capsule-conversion. |
| | Means of Compliance for DRIP Entity Tags as UAS RID Identifiers |
| |
|
This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-dutt-nvo3-rfc7348bis-00.txt |
| | Date: |
04/11/2024 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Kenneth Duda, Puneet Agarwal, Larry Kreeger, T. Sridhar, Mike Bursell, Chris Wright, Ali Sajassi |
| | Working Group: |
Individual Submissions (none) |
|
This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. |
| | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay on the OAM transit and decapsulating nodes. |
| | Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors |
| |
|
A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document proposes a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. |
| | Automatically Connecting Stub Networks to Unmanaged Infrastructure |
| |
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-14.txt |
| | Date: |
04/11/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 data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. 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 may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet are used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along a path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can also be generalized for other network resource semantics and functions. |
| | More Control Operators for CDDL |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (Bytes, Integers, JSON, Printf-style formatting) and for an operation on text. |
| | CoAP Management Interface (CORECONF) |
| |
| | draft-ietf-core-comi-19.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. |
| | Finding Tracking Tags |
| |
| | draft-ietf-dult-finding-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Christine Fossaceca, Eric Rescorla |
| | Working Group: |
Detecting Unwanted Location Trackers (dult) |
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. This document defines the protocol by which devices report tags they have seen and by which owners look up their location. |
| | Detecting Unwanted Location Trackers Accessory Protocol |
| |
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. |
| | 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 to customers who have specific requirements on their connectivity, such as guaranteed resources, latency, or jitter. Enhanced VPNs require 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-Link State (BGP-LS) with Multi-Topology (MT). |
| | IP Tunnels in the Internet Architecture |
| |
|
This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | JOSE: Deprecate 'none' and 'RSA1_5' |
| |
|
This draft updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. |
| | YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
| |
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| | YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. |
| | YANG Data Model for IS-IS Segment Routing MPLS PICS |
| |
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| | Low Overhead Media Container |
| |
| | draft-mzanaty-moq-loc-04.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Mo Zanaty, Suhas Nandakumar, Peter Thatcher |
| | Working Group: |
Individual Submissions (none) |
|
This specification describes a media container format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT) [MoQTransport], with the goal of it being a low-overhead format. It further defines the LOC Streaming Format for the MOQ Common Catalog format [MoQCatalog] for publishers to annouce and describe their LOC tracks and for subscribers to consume them. The specification also provides examples to aid application developers for building media applications over MOQT and intending to use LOC as the streaming format. |
| | 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks |
| |
|
This document defines a new type of segment for Segment Routing, 4map6 segment, which is an IPv4/IPv6 conversion function based on stateless mapping rules running in PE nodes for the delivery of IPv4 services over IPv6-only network. At the same time, the BGP Prefix- SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | NTS extensions for enabling pools |
| |
| | draft-venhoek-nts-pool-01.txt |
| | Date: |
03/11/2024 |
| | Authors: |
David Venhoek, Folkert de Vries, Marc Schoolderman |
| | Working Group: |
Individual Submissions (none) |
|
The aim of this document is to describe a proof of concept system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple downstream servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. |
| | 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. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Multi-path |
| |
|
STAMP is typically used to perform the measurement of one-way and round-trip performance metrics. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends STAM with a Multi-path TLV to implement the multi-path performance measurement, which can help the operators to know the performance of network comprehensively and efficiently. |
| | Interface to In-Network Functions (I2INF): Problem Statement |
| |
|
This document specifies the problem statement for the Interface to In-Network Functions (I2INF) for user services both on the network- level and application-level. In-Network Functions (INF) include In- Network Computing Functions (INCF) which are defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). INF also includes In-Network Application Functions (INAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of INFs in a target network. This document investigates the need for a standard framework with the interfaces for INFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor INFs. |
| | A Framework for the Interface to In-Network Functions (I2INF) |
| |
|
This document specifies a framework to define Interface to In-Network Functions (I2INF) for user services both on the network-level and application-level. In-Network Functions (INF) include In-Network Computing Functions (INCF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). INF also includes In-Network Application Functions (INAF) which appear in the context of Internet-of-Things (IoT) Devices, Software- Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2INF framework, which includes components and interfaces to configure and monitor the INFs that implement applications and services. |
| | Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptograph (PQC) algorithms for digital signature like NIST [ML-DSA], however it takes time for new cryptograph algorithms to mature, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. |
| | BGP Flow Specification Extensions for Scheduling |
| |
|
BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time. This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic. |
| | Extensible YANG model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG compatible encodings such as XML, JSON or CBOR. |
| | An Architecture for IP in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. The IP protocol stack used on Internet is based on assumptions of shorter delays and mostly uninterrupted communications. This document describes the architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links, signaling buffer storage near capacity, adjusting transport protocols configuration and application protocols timers. This architecture applies to Moon, Mars or in general interplanetary networking. |
| | DKIM2 Why DKIM needs replacing,and what a replacement would look like |
| |
|
This memo provides a rationale and outline design for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides useful and secure semantics for RTR Protocol in particular as a single connection could carry multiple requests over streams, enabling much better efficiency and performance for both peers. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | TLS Client Puzzles Extension |
| |
| | draft-venhoek-tls-client-puzzles-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
David Venhoek, -, Marc Schoolderman, Erik Nygren, Samuel Erb, Alex Biryukov, Dmitry Khovratovich, Ari Juels |
| | Working Group: |
Individual Submissions (none) |
|
Client puzzles allow a TLS server to defend itself against asymmetric DDoS attacks. In particular, it allows a server to request clients perform a selected amount of computation prior to the server performing expensive cryptographic operations. This allows servers to employ a layered defense that represents an improvement over pure rate-limiting strategies. Client puzzles are implemented as an extension to TLS 1.3 [RFC8446] wherein a server can issue a HelloRetryRequest containing the puzzle as an extension. The client must then resend its ClientHello with the puzzle results in the extension. |
| | Interfaces of In-Network Functions in Data Center Networking |
| |
|
In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Functions (INF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these INFs. This document focuses on the applicability of INFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these INFs. |
| | SCONE Privacy Properties and Incentives for Abuse |
| |
|
This document discusses privacy properties of the SCONE metadata or network-to-host signals. This covers questions that were raised during the IETF 119 BoF and subsequent discussions. It is not intended to be published as a separate RFC but might be incorporated as a part of the security considerations or other content within eventual SCONE RFCs together with other documents covering security considerations. Other documents will address additional aspects of the security considerations for SCONE metadata. |
| | APIs To Expose SCONE Metadata to Applications |
| |
| | draft-eddy-scone-api-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Wesley Eddy, Abhishek Tiwari, Alan Frindell |
| | Working Group: |
Individual Submissions (none) |
|
This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using the SCONE 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. |
| | SCONE Net Neutrality |
| |
|
This document provides a response to the question of whether SCONE can be used to undermine Net Neutrality provisions for network users. It proposes guardrails to ensure Net Neutrality principles are maintained. |
| | SCONE Need for Defining A New On-Path Signaling Mechanism |
| |
| | draft-tomar-scone-ecn-00.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Anoop Tomar, Lars Ihlar, Wesley Eddy, Ian Swett, Abhishek Tiwari, Matt Joras |
| | Working Group: |
Individual Submissions (none) |
|
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONE use-case. The SCONE objective is to optimize user QoE for streaming media/video services through network assisted application-level self-adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs). |
| | Domain Name System in Mostly Isolated Networks |
| |
|
This document lists operational methods to enable local DNS name resolving on an isolated network, where that network have intermittent reachability to Internet and/or have very long delays, such as deep space networks, disabling the real-time query and response flow to the authoritative name servers on Internet. |
| | Domain Transfer Authorization Using Cryptographic Signatures |
| |
|
This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a cryptographic signature-based validation system that enables authorization based on PKIs (Public Key Identification) and hands over control of the domain to a specific next controller identified by their PKI. The process is designed to be fully backward compatible with existing EPP systems through staged incremental upgrades. |
| | Current practices for new cryptography at the IETF |
| |
|
This document describes the current practices for handling new cryptography within the IETF. Some of these practices are informal and depend on individuals in certain relevant roles, such as Working Group Chairs, the Security Area Directors and the Independent Stream Editor. This document is intended to increase consistency and transparency in how the IETF handles new cryptography, such as new algorithms, ciphers and new primitives or combiners, by providing a reference for the cryptographic practices within the IETF. This document does not describe any new policies and does not prohibit exceptions in the described current practices. |
| | A YANG module for entitlement inventory |
| |
|
This document proposes a YANG module with an inventory of entitlements. The model helps manage details about entitlements, such as their scope, how they are assigned, and when they expire. The model introduces the a descriptive definition of features and use restriction that can help a entitlement admistration an understanding of the state of their assets and the capabilities available across the network. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
| | draft-ietf-opsawg-ipfix-alt-mark-01.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Massimo Nilo |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | 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). |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows last hop routers to learn about new sources using PFM messages, without the need for initial data registers, Rendezvous Points or shared trees. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document also defines methodologies that enhance forwarding efficiency in PFM-SD deployments. |
| | A CBOR Tag for Unprotected CWT Claims Sets |
| |
| | draft-ietf-rats-uccs-12.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, message authentication code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and processing considerations, and discusses security implications of using unprotected claims sets. // (This editors' note will be removed by the RFC editor:) The // present revision (–12) contains remaining document changes based // on feedback from the IESG evaluation and has been submitted as // input to IETF 121. |
| | EAT Media Types |
| |
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). |
| | 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 SRv6 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. |
| | IANA Registry Updates for TLS and DTLS |
| |
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries and adds a "Comments" column to all active registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. |
| | Transport Options for UDP |
| |
|
Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP length. |