| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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]. |
| | Conceptual Model for Digitized Emblems |
| |
|
This document describes the conceptual models of use for digital emblems. |
| | 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. |
| | 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). |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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.] |
| |
|
| |
| | 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. |
| | 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. |
| | ESP Echo Protocol |
| |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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 |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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). |
| | 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. |
| | 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. |
| | 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). |
| |
|
| |
| | 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/. |
| | 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. |
| | 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. |
| | 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 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. |
| | 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). |