| |
|
| |
| | Encrypted DNS Server Redirection |
| |
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. |
| | BRSKI discovery and variations |
| |
|
This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators, especially in the face of variations in the protocols that can introduce non-interoperability when not equally supported by both responder and initiator. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-ietf-asdf-nipc-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices. The described interface is extensible. This memo initially describes Bluetooth Low Energy and Zigbee as they are the most commonly deployed. |
| | Extended Procedures for EVPN Optimized Ingress Replication |
| |
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. |
| | Weighted HRW and its applications |
| |
|
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. |
| | Meticulous Keyed ISAAC for BFD Authentication |
| |
|
This document describes a new BFD Authentication mechanism, Meticulous Keyed ISAAC. This mechanism can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used as an authenticated signal to maintain a session in the the "Up" state. |
| | A YANG Data Model for Network Tester Management |
| |
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. |
| | A YANG Data Model for Optical Impairment-aware Topology |
| |
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks. |
| | A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) |
| |
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| | A YANG Data Model for WDM Tunnels |
| |
| | draft-ietf-ccamp-wdm-tunnel-yang-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Use cases,Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework |
| |
|
This document provides general overarching guidelines for control and management of packet over optical converged networks with coherent pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on coherent pluggables. The document provides a gap analysis to solve the use cases. |
| | Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option |
| |
| | draft-tllq-tsr-05.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Ted Lemon, Liang Qin |
| | Working Group: |
Extensions for Scalable DNS Service Discovery (dnssd) |
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD Advertising Proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. |
| | ICN Challenges for Metaverse Platform Interoperability |
| |
|
This document explores the potential of Information-Centric Networking (ICN) to enhance interoperability between metaverse platforms. ICN's content-centric approach, in-network caching, and inherent security features can address key challenges such as scalability, low-latency performance, data ownership, and standardization needs. It also identifies these challenges and proposes solutions to optimize data sharing, enable efficient content distribution, and enforce secure access controls. |
| | YANG Model for Border Gateway Protocol (BGP-4) |
| |
| | draft-ietf-idr-bgp-model-18.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Mahesh Jethanandani, Keyur Patel, Susan Hares, Jeffrey Haas |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. |
| | Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP |
| |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. |
| | A summary of security-enabling technologies for IoT devices |
| |
|
The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies. |
| | Responsiveness under Working Conditions |
| |
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of latency, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-22.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. |
| | Deep Audio Redundancy (DRED) Extension for the Opus Codec |
| |
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. |
| | Common YANG Data Types |
| |
|
This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. |
| | IPv6-only Terminology Definition |
| |
|
This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. |
| | Flowspec Indirection-id Redirect for SRv6 |
| |
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | Protocol Assisted Protocol (PASP) |
| |
|
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP( BGP Monitoring Protocol), for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PASP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues. |
| | Using Flex-Algo for Segment Routing (SR) based Network Resource Partition (NRP) |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique Flexible Algorithm (Flex-Algo), which can provide constraint-path computation based on the customized topological constraints. This document specifies a mechanism to build Segment Routing (SR) based NRPs by combining SR Flex-Algo and IGP L2 bundles with minor extensions. |
| | Advertising SRv6 SIDs for Layer 2 Bundle Member Links in IGP |
| |
|
There are deployments where the Layer-3 interface on which IGP operates is a Layer-2 interface bundle. Existing IGP advertisements only support advertising link attributes of the Layer-3 interface. If entities external to IGP wish to control traffic flows on the individual physical links that comprise the Layer-2 interface bundle, link attribute information about the bundle members is advertised by IGP extensions for Layer-2 (L2) bundle. When Segment Routing over IPv6 (SRv6) is used with Layer-2 interface bundle to control traffic flows on the individual member links, the SRv6 SIDs which represent the Layer 2 member links of the L2 bundle needs to be advertised in IGP. This document proposes the IGP extensions to advertise the SRv6 SIDs of the Layer 2 (L2) bundle member links. |
| | Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation |
| |
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. The present version of this document is mostly a proof of concept, but was deemed useful to obtain initial feedback on the approach taken. |
| | PCEP Extension for Bounded Latency |
| |
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry the bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. |
| | Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks |
| |
|
Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. |
| | Considerations of network/system for AI services |
| |
| | draft-hong-nmrg-ai-deploy-07.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Ho-Sun Yoon, Pedro Martinez-Julia |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | Generalized IPv6 Tunnel (GIP6) |
| |
|
This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| | draft-fossati-tls-attestation-08.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Hannes Tschofenig, Yaron Sheffer, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, Arto Niemi, Thomas Fossati |
| | Working Group: |
Individual Submissions (none) |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. |
| | Multi-Topology in PIM |
| |
| | draft-xz-pim-flex-algo-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Individual Submissions (none) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | Additional addresses for QUIC |
| |
|
This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-liu-sidrops-rtr-yang-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Jeffrey Haas, Hongwei Liu, Di Ma |
| | Working Group: |
Individual Submissions (none) |
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| | A Mechanism for Encoding Differences in Paired Certificates |
| |
|
This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to construct the paired certificate and perform certification path validation using the constructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. |
| | Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP) |
| |
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 6083. DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions. |
| | Maintaining Protocols Using Grease and Variability |
| |
|
Long-term interoperability of protocols is an important goal of the network standards process. Deployment success can depend on supporting change, which can include modifying how the protocol is used, extending the protocol, or replacing the protocol. This document presents concepts, considerations, and techniques related to protocol maintenance, such as greasing or variability. The intended audience is protocol designers and implementers. |
| | Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies |
| |
|
The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. |
| | SW103K PROTOCOL |
| |
|
What Problems Does This Protocol Solve? The SW103k protocol addresses several challenges that arise when transporting data over networks with limited bandwidth, latency constraints, and data integrity concerns. Specifically, it provides a compression and decompression mechanism designed to: Optimize Bandwidth Utilization: In environments where bandwidth is limited, such as IoT networks, satellite communications, and mobile data transfers, SW103k reduces the amount of data sent over the wire by compressing data in transit, thus saving bandwidth. Improve Data Transfer Speeds: By compressing data before transmission, the protocol reduces the volume of data that needs to be transferred, which improves transfer speeds, especially in networks where bandwidth is a bottleneck. Ensure Data Integrity: In addition to compression, SW103k integrates error- checking mechanisms that ensure data arrives intact. This helps mitigate issues in unreliable network conditions where packet loss or corruption might occur. Security Considerations: The protocol incorporates optional encryption to provide confidentiality during data transmission. This is especially useful in scenarios where sensitive data needs to be transferred, like financial transactions or health data over potentially insecure networks. How Does This Protocol Work? The SW103k protocol operates in a client-server architecture, where the sender (client) compresses the payload using a predefined compression algorithm before transmitting it to the receiver (server). The receiver then decompresses the data back into its original form. Key Components: Compression Algorithm: SW103k uses a hybrid compression algorithm combining LZ77 and Huffman encoding, ensuring efficient data compression with minimal overhead. The protocol negotiates the compression parameters (e.g., window size) at the start of each connection. Decompression Mechanism: The receiver is responsible for decompressing the data using the same parameters agreed upon during the initial handshake. The decompression process is optimized for low-latency environments to ensure the data is available with minimal delay. Transport Layer: SW103k functions over standard transport layers such as TCP or QUIC, and adds a lightweight layer that manages compression, decompression, and error-checking. The protocol header contains metadata about the compression type and error-checking mechanism used. Error Checking: SW103k includes a checksum or CRC32 in each transmission block, ensuring that data corruption can be detected and retransmitted if necessary. Comparison with Other Transport Protocols Compared to other transport protocols like TCP or QUIC, SW103k doesn’t replace them but adds an additional layer of compression and decompression to the transport process. Unlike raw TCP or QUIC, which primarily focus on connection reliability and speed, SW103k introduces bandwidth optimization through compression, which makes it particularly useful in constrained environments. Here’s how SW103k compares with other protocols: TCP: TCP provides reliable transmission, but it does not natively compress data. While you can use application-layer compression with TCP, SW103k integrates compression at the transport layer, optimizing both compression and transmission. QUIC: QUIC focuses on speed and low-latency transmissions, especially over unreliable networks. SW103k could potentially be layered on top of QUIC to introduce compression, making it useful in high-latency networks like mobile or satellite. TLS: TLS ensures security over transmission but doesn’t compress data. SW103k can work with TLS, where compressed data is first encrypted before being transmitted, adding an additional layer of bandwidth efficiency. SCTP: Like TCP, SCTP focuses on reliability, especially for message-based communications. SW103k could work with SCTP when reliability and bandwidth optimization are both critical. Why Choose SW103k Over Existing Protocols? SW103k could be chosen over existing protocols when: Bandwidth Optimization is Critical: In environments like IoT networks, satellite communications, or mobile data transfer, where bandwidth is expensive or limited, SW103k reduces the overall data transferred by compressing the payload before transmission. Minimal Processing Overhead: SW103k has been designed to offer high levels of compression with low computational overhead, making it ideal for low- power devices or systems with limited resources. Easy Integration with Existing Protocols: SW103k is designed to work alongside existing transport protocols (e.g., TCP, QUIC) without needing major architectural changes. It acts as a lightweight add-on for compression and decompression, simplifying adoption for legacy systems. Security Issues Raised by Using This Protocol Using the SW103k protocol introduces a few potential security considerations: Compression-related Attacks: Compression algorithms may be susceptible to attacks such as the CRIME or BREACH attacks, which exploit the predictable nature of compressed data. Implementing padding or randomized inputs to the compression process could help mitigate these risks. Data Integrity and Tampering: Since the protocol involves compressing and decompressing data, there's a risk that data might be tampered with during transmission. SW103k addresses this by incorporating checksum or CRC32 mechanisms to verify the integrity of each transmission block. Encryption Considerations: If sensitive data is being transmitted using SW103k, the protocol needs to ensure that the compression process doesn't leak information about the original data. It’s recommended that data be encrypted before compression or using TLS in conjunction with SW103k for secure transmissions. Denial-of-Service (DoS) Vulnerabilities: Malicious users could flood the server with decompression requests, consuming significant CPU resources. Implementing rate limiting or requiring authenticated connections before processing requests can reduce the attack surface. Concrete Examples of What is Missing When I refer to the current document not containing anything concrete, I mean that the draft lacks crucial technical details and implementation guidance that protocol implementers or reviewers need to understand the protocol’s purpose and function. For example: Detailed Algorithm: Instead of just saying “SW103k compresses data,” a concrete description would include the actual algorithm (e.g., how the hybrid of LZ77 and Huffman encoding works) and pseudocode to explain how compression and decompression happen. Message Formats: In protocols like HTTP/2 or QUIC, message formats are clearly defined. Each byte or bit has a meaning in the headers, body, and control information. SW103k should include message diagrams showing what the protocol header looks like, how metadata is transmitted, etc. State Machine or Flow Diagrams: Many transport protocols include flow diagrams showing how the protocol handles different network events (e.g., connection initiation, packet retransmission). SW103k should include this to illustrate the typical lifecycle of a connection. Code Examples: Providing actual working code that developers could use to implement SW103k would be useful. This could be a Python or C library that demonstrates how compression is performed and how the protocol interacts with the transport layer. Conclusion: Actionable Next Steps for Internet Draft To move forward with SW103k as an Internet Draft for the IETF: Develop a Detailed Specification: Include the detailed design and behavior of the protocol, including the compression algorithm, transport layer interaction, and flow control. Provide Concrete Examples: Add sample pseudocode or protocol header diagrams that illustrate how the protocol works in practice. Security Considerations: Detail the potential risks (e.g., CRIME/ BREACH attacks) and provide mitigation strategies to secure the protocol. Test Cases and Implementation: Provide a reference implementation or a set of test cases for developers to try out the protocol in different environments. |
| | Per Resource Events |
| |
|
Per Resource Events is a minimal protocol built on top of HTTP that allows clients to receive notifications directly from any resource of interest. The Per Resource Events Protocol (PREP) is predicated on the idea that the most intuitive source for notifications about changes made to a resource is the resource itself. |
| | Opportunistic TCP-AO with TLS |
| |
| | draft-piraux-tcp-ao-tls-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. |
| | BGP over TLS/TCP |
| |
|
This document specifies the utilization of TCP/TLS to support BGP. |
| | Benchmarking Methodology for Reliable Transport Protocols in Integrated Space and Terrestrial Networks |
| |
|
This document defines the terminology and methodology for conducting performance benchmarking of the transport protocols for low-earth orbit satellite user terminals within emerging integrated space and terrestrial networks (ISTN). It encompasses the test environment setup and benchmarking methodology. The objective of this document is to enhance the applicability, repeatability, and transparency of performance benchmarking for reliable transport protocols (e.g. TCP and QUIC) in ISTNs. |
| | Joint Exposure of Network and Compute Information for Infrastructure-Aware Service Deployment |
| |
|
Service providers are starting to deploy computing capabilities across the network for hosting applications such as distributed AI workloads, AR/VR, vehicle networks, and IoT, among others. In this network-compute environment, knowing information about the availability and state of the underlying communication and compute resources is necessary to determine both the proper deployment location of the applications and the most suitable servers on which to run them. Further, this information is used by numerous use cases with different interpretations. This document proposes an initial approach towards a common exposure scheme for metrics reflecting compute and communication capabilities. |
| | Guidance for HTTP Capsule Protocol Extensibility |
| |
|
This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. |
| | X-Wing: general-purpose hybrid post-quantum KEM |
| |
|
This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 5681, RFC 9002, RFC 9260, and RFC 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | Definition and Problem Statement of consistent inter-domain routing and forwarding |
| |
|
This document introduces what the forwarding consistency is and why forwarding inconsistency is prevalent in the Internet, describes the risks of forwarding inconsistency and defines the requiremenets for forwarding consistency. |
| | No Further Fast Reroute for SRv6 Service SID |
| |
|
In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR flags for SRv6 Service SIDs in BGP messages. |
| | Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives |
| |
| | draft-havel-nmop-digital-map-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Olga Havel, Benoit Claise, Oscar de Dios, Ahmed Elhassany, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
This document shares experience in modelling Digital Map based on the IETF RFC 8345 topology YANG modules and some of its augmentations. The document identifies a set of open issues encountered during the modelling phases, the missing features in RFC 8345, and some perspectives on how to address them. For definition of Digital Map concepts, requirements and use cases please refer to the "Digital Map: Concept, Requirements, and Use Cases" document. 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/OlgaHuawei. |
| | IKEv2 Support for Anti-Replay Status Notification |
| |
|
Although RFC 4302 and RFC 4303 don't prohibit using Extended Sequence Number (ESN) when the anti-replay function is not enabled, many IPsec implementations require ESN to be used only with anti-replay. Therefore, failing to negotiate the use of ESN when the anti-replay is disabled will cause the sequence numbers to exhaust rapidly in high-traffic-volume scenarios, leading to the frequent rekey of Child SAs. This document defines the REPLAY_PROT_AND_ESN_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peer of its replay protection status and capability of using ESN without anti-replay when creating the Child SAs, to address the above problem. |
| | BGP Link State Extensions for Scalable Network Resource Partition |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. |
| | Applicability of GMPLS for fine grain Optical Transport Network |
| |
|
ITU-T Recommendation ITU-T G.709/Y.1331 (2020) Amd.3 (03/2024) introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. |
| | Compute-Aware Traffic Steering for Midhaul Networks |
| |
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. |
| | 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS |
| |
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS procedures. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. |
| | Web Proxy Auto Discovery Next Generation |
| |
|
This specification aims to modernize Web Proxy Automatic Discovery ([WPAD]) which was defined in 1997. At that time, the World Wide Web was much earlier in its evolution. This specification provides more modern discovery mechanisms and incorporates [PVD] 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/joshco/wpadng. |
| | Secure Nameserver Selection Algorithm for DNS Resolvers |
| |
|
Nameserver selection algorithms employed by DNS resolvers are not currently standardized in the DNS protocol, and this has lead to variation in the methods being used by implementations in the field. Recent research has shown that some of these implementations suffer from security vulnerabilities. This document provides an in-depth analysis of nameserver selection utilized by mainstream DNS software and summarizes uncovered vulnerabilities. It then provides recommendations for defending against these security and availability risks. Designers and operators of recursive resolvers can adopt these recommendations to improve the security and stability of the DNS. |
| | Handling Multiple Verifiers in the RATS Architecture |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and generates Attestation Results needed by Relying Parties. This document provides a solution to inconsistent behaviors of the Verifier in the RATS architecture by introducing a mechanism to aggregate Attestation Results collected from multiple Verifiers at the Relying Party while simplifying its policy and operation. |
| | Attester Groups for Remote Attestation |
| |
|
This document proposes an extension to the Remote Attestation Procedures architecture as defined in [RFC9334] by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. |
| | YANG Data Models for fine grain Optical Transport Network |
| |
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1G client signals in transport network. |
| | Advertising Network Resource Partition (NRP) Policy in BGP |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and the 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 or RFC 9543 network slice services. For the instantiation of an NRP, NRP- specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy. This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality. |
| | WIMSE Token Exchange and Translation Protocol |
| |
|
The specification defines the processes of token exchange and token translation for workloads. Token exchange is introduced in [RFC8693], allowing the exchange of access tokens, OpenID Connect ID Tokens, and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by [RFC8693]. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Kerberos service tickets, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT OAuth 2.0 Acesss Tokens [RFC9068], CWT [RFC8392], and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in [RFC8693], and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in (todo: add link to use cases doc). |
| | HTTP Resource Versioning |
| |
|
HTTP resources change over time. Each change to a resource creates a new "version" of its state. HTTP systems often need a way to identify, read, write, navigate, and/or merge these versions, in order to implement cache consistency, create history archives, settle race conditions, request incremental updates to resources, interpret incremental updates to versions, or implement distributed collaborative editing algorithms. This document analyzes existing methods of versioning in HTTP, highlights limitations, and sketches a more general versioning approach that can enable new use-cases for HTTP. An upgrade path for legacy intermediaries is provided. |
| | 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. |
| | Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile |
| |
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for applications that use Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | PCEP over QUIC |
| |
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. |
| | Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6) |
| |
|
This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | Symmetric HTTP/2 Extension |
| |
|
This draft defines an HTTP/2 [RFC9113] extension to support Symmetric HTTP, which makes a simplifying assumption that the client-side HTTP server is only accessible and addressible by the server that accepted the HTTP/2 connection. 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/joshco/sh2. |
| | Scenarios and Deployment Considerations for High Performance Wide Area Network |
| |
|
This document describes the typical scenarios and deployment considerations for High Performance Wide Area Networks (HP-WANs). It also provides simulation results for data transmission in WANs and analyses the impacts on throughput.. |
| | A Use Case of Network Operation for Telecom Cloud |
| |
|
This document discusses the network operation issues of telecom cloud. It first introduces a typical use case of network for telecom cloud, then illustrates the requirements for network operation for telecom cloud from the perspective of TSP, and proposes a general network operation model for telecom cloud. It also analyzes the gap based on the current technological status. |
| | Extensions to IOAM Trace Option for Carrying Fixed-Size Data |
| |
|
The IOAM Trace-Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the transited IOAM- capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed-size data, the length of this kind of data is fixed and doesn't vary with the transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. |
| | Framework for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document proposes a comprehensive framework to address the challenges of efficient, reliable, and cost-effective large volume data transmission over Wide Area Networks (WANs). The framework focuses on planning and managing traffic paths, network slicing, and utilizing multi-level network buffers. It introduces dynamic path scheduling and advanced resource allocation techniques to optimize network resouce and minimize congestion. By leveraging cross-device buffer coordination and real-time adjustments, the framework ensures high throughput and low latency, meeting the demands of modern, data- intensive applications while providing a robust solution for large- scale data transmission. |
| | YANG Templates |
| |
|
NETCONF and RESTCONF protocols provide programmatic operation interfaces for accessing configuration data modeled by YANG. This document defines the use of YANG-based configuration template mechanism so that the configuration data could be defined as template and applied repeatedly to avoid the redundant definition of identical Configuration and ensure consistency of it. |
| | In-Network Congestion Notification |
| |
|
This document describes an in-network congestion notification mechanism for the provider network, to enable the real-time Tactical Traffic Engineering on the provider edge node. |
| | A YANG Data Model of Performance Management Streaming |
| |
|
This document provides a YANG data model of performance management streaming in network equipment. It defines types of parameters, and their measurements and reporting methods by periodic and event notifications. |
| | Use Cases and Requirements for SCONE in Massive Data Transmission |
| |
|
This document outlines a use case for Standard Communication with Network Elements (SCONE) in the context of massive data transmission (MDT). From the described use case, it derives a set of signaling requirements for the communication between applications and network elements. |
| | Analysis of Service Management Interface for Cloud-network Convergence |
| |
|
This document analyzes the cloud-network convergence service management interface. |
| | PCEP Extension for Fine Grain Optical Transport Network (fgOTN) |
| |
|
This document introduces the PCEP extension used for computed fgOTN path from the PCE to the PCC. |
| | IFIT-based anomaly monitoring and tracing in data circulation |
| |
|
This document proposes a deployment scheme of IFIT-based anomaly monitoring and tracing in data circulation. Use cases and requirements are discussed, and a deployment scheme is described in detail. |
| | Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document defines a format for transport of hints about Trust Anchors of trusted third parties when using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | SCONE Real Time Communication Requirement |
| |
|
In real-time communication (RTC) applications, low latency is essential, but unstable network conditions make it challenging. Traditional control loop reacts slowly and inaccurately to network changes. A new approach is proposed, communicating bandwidth and queue information from the bottleneck to the end-host for more accurate control. |
| | EPP XML to RPP JSON conversion rules |
| |
|
This document describes the rules for converting The Extensible Provisioning Protocol (EPP) [RFC5730] XML based messages to a JSON [RFC8259] for use with the RESTful Provisioning Protocol (RPP). |
| | A congestion control mechanism based on distributed AIDC lossless network |
| |
|
This document proposes a congestion control mechanism based on distributed AIDC lossless network. It can effectively solve the problem of declining model training performance due to congestion and packet loss on long-distance links when training large models across multiple data centers within a region. In addition, this document outlines the practice scenario of this congestion control mechanism. |
| | Fast Fault Tolerance Architecture for Programmable Datacenter Networks |
| |
| | draft-fft-architecture-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Dan Li, Kaihui Gao, Shuai Wang, Li Chen, Xuesong Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces a fast rerouting architecture for enhancing network resilience through rapid failure detection and swift traffic rerouting within the programmable data plane, leveraging in-band network telemetry and source routing. Unlike traditional methods that rely on the control plane and face significant delays in traffic rerouting, the proposed architecture utilizes a white-box modeling of the data plane to distinguish and analyze packet losses accurately, enabling immediate identification for link failures (including black- hole and gray failures). By utilizing real-time telemetry and SR- based rerouting, the proposed solution significantly reduces rerouting times to a few milliseconds, offering a substantial improvement over existing practices and marking a pivotal advancement in fault tolerance of datacenter networks. |
| | On-Path Proxy Discovery |
| |
|
This document surveys possibilities for On-Path Proxy Discovery (OPPD). It is meant to help the conversation in a planned side meeting at IETF-121 in Dublin (see the github page linked under "About This Document" for coordinates). The draft title indicates PANRG as a target of this document just because we thought that PANRG should be informed. What a suitable target is, and if this is even the right type of document, should all be discussed at the side meeting. |
| | Framework of Distributed AIDC Network |
| |
|
With the rapid development of large language models, it puts forward higher requirements for the networking scale of data centers. Distributed model training has been proposed to shorten the training time and relieve the resource demand in a single data center.This document proposes a framework to address the challenge of efficient lossless interconnection and reliable data transmission between multiple data centers, which can connect multiple data centers to form a larger cluster through network connection. The document further conducts in-depth research on the key technologies and application scenarios of this distributed AIDC network. |
| | Extensions to BIER Tree Engineering (BIER-TE) for Large Multicast Domains and 1:1 Protection |
| |
|
BIER-TE extends BIER with tree engineering capabilities and can be supported by almost the same hardware. However, a bitstring in BIER- TE hold bits for BFERs and links, which effects that the size of supportable topologies in terms of BFERs is smaller for BIER-TE than for BIER. While for BIER, subsets can be utilized to improve scaling to large multicast domains, this mechanism requires adaptation for BIER-TE. In this document, requirements for BIER-TE subsets are defined, a mechanism is described for how BIER-TE packets can reach their subsets using tunneling, and 1:1 protection for the entire BIER-TE multicast tree is explained. The concept utilizes egress protection for reaching a subset when the ingress BFIR of the subset fails. |
| | 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. |
| | Inter-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | MLS Associated parties |
| |
|
The Messaging Layer Security (MLS) protocol allows a group of clients to exchange symmetric keys, agree on group state and send application messages. The main purpose of an MLS group is thus to facilitate agreement on group state and key material between the members of the group. In some cases, however, it is useful to share agreement on the (public) group state, as well as key material with another party that is not a full member of the group. This document describes a safe extension to do just that. |
| | Flexicast QUIC: combining unicast and multicast in a single QUIC connection |
| |
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and multicast distribution trees. |
| | Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane |
| |
|
This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability. |
| | Analysis for the Adverse Effects of LEO Mobility on Internet Congestion Control |
| |
| | draft-lai-ccwg-lsncc-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Qi Zhang |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a performance analysis on various congestion control algorithms(CCAs) in an operational low-earth orbit (LEO) satellite network (LSN). Internet CCAs are expected to perform well in any Internet path, including those paths with LEO satellite links. Our analysis results reveal that existing CCAs struggle to deal with the drastic network variations caused by the mobility of LEO satellites, resulting in poor link utilization or high latency. Further, this document discusses the key challenges of achieving high throughput and low latency for end-to-end connections over an LSN, and provides useful information when the LSN-specific congestion control principles for the Internet is standardized in the future. |
| | MLS Split Commits |
| |
|
This document describes an extension to the MLS protocol [RFC940] that improves its efficiency in terms of per-member download size. This comes at essentially no cost. In essence, this document defines a new message type called split commit which replaces regular MLS commits. Unlike regular commits, a split commit can be "split" by the Delivery Service (DS) into much smaller per-member commits, one for each receiving member. The size of a per-member commit is always logarithmic in the group size, while the size of a regular MLS commit can be linear. This extension works in settings with a DS that can do the splitting which can be demanding with encrypted MLS handshake messages. This is motivated by academic research [KKP22], [HKPPW22], [AHKM22]. |
| | DHCPv4 Option for IPv4 routes with IPv6 nexthops |
| |
|
// This draft lives at https://github.com/eqvinox/dhc-route4via6 As a result of the shortage of IPv4 addresses, installations are increasingly recovering IPv4 addresses from uses where they are not strictly necessary. One such situation is in establishing next hops for IPv4 routes, replacing this use with IPv6 addresses. This document describes how to provision DHCP-configured hosts with their routes in such a situation. |
| | A YANG Data Model for Passive Network Inventory |
| |
|
This document presents a YANG data model for passive device inventory information. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. |
| | MLS Wire Formats for PublicMessage and PrivateMessage without authenticated_data |
| |
|
This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD. |
| | Path Energy Traffic Ratio API (PETRA) |
| |
| | draft-petra-green-api-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Alberto Rodriguez-Natal, Luis Contreras, Alejandro Muniz, Marisol Palmero, Fernando Munoz, Jan Lindblad |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. |
| | Framework for Getting Ready for Energy-Efficient Networking(GREEN) |
| |
|
This document describes a framework for a framework for Getting Ready for Energy-Efficient Networking(GREEN). |
| | A Use case for Green Computing-Aware Traffic Steering |
| |
|
This draft describes a compute-aware use case for services with green energy requirements. This use case considers both network, computation and energy metrics when selecting a service instance. |
| | Initial Considerations about QDKN Protocols |
| |
| | draft-danet-qkdn-considerations-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Martin Stiemerling, Fabian Seidl, Malte Bauch, Neil-Jocelyn Schark, Johanna Henrich |
| | Working Group: |
Individual Submissions (none) |
|
Quantum communication modules connected via a link, either via fiber or free-space communications, have been used since a while to distribute random numbers as secure keys, but there are other use cases, such as time synchronization. By today, a number of research and industrial efforts are underway to built complete networks, primary for secure key distribution, i.e., so-called Quantum Key Distribution Networks (QKDN). This memo briefly explores the space of QKDNs and identifies spots of potentials interest to develop standardized protocols specific for such networks. |
| | A new QUIC version for network property communication |
| |
|
This document describes a new QUIC version. The proposed wire format and a set of procedures can be used to communicate throughput advice between an endpoint and an on-path network element. Throughput advice are sent in QUIC packets of a new QUIC version. These QUIC packets are sent adjecent to established QUIC version 1 and 2 connections, within the same UDP 4-tuple. |
| | UDP Option Extension for 5G XR Media Services |
| |
|
Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in 3GPP. The service features at achieving high data rate, high reliability and low latency. The multiple streams of an XRM service use IP sessions to transport media contents with the provisioning of advanced QoS settings. The XRM Metadata or PDU Set QoS marking is used to differentiate the PDU Set requirements to the 5GS. RTP header extension (HE), as defined by 3GPP, can be used to transport XRM Metadata for un-encrypted media streams, while the encrypted XRM streams post challenges for UPFs to extract the Metadata. This draft proposes to use the IETF UDP Option extension, by defining a new SAFE type, to help enhance the carry & transport of encrypted XRM Metadata. |
| | IPv6 Address Accountability Considerations |
| |
|
Hosts in IPv4 networks typically acquire addresses by use of DHCP, and retain that address and only that address while the DHCP lease remains valid. In IPv6 networks, hosts may use DHCPv6, but may instead autoconfigure their own global address(es), and potentially use many privacy addresses over time. This behaviour places an additional burden on network operators who require address accountability for their users and devices. There has been some discussion of this issue on various mail lists; this text attempts to capture the issues to encourage further discussion. |
| | YANG Data Models for Security Configuration Check |
| |
|
Security configuration refers to the status setting of product security features/functions to reduce network security risks during product use. This document defines YANG data models for the security configuration check. |
| | Multi-Perspective Issuance Corroboration (MPIC) Service |
| |
|
This memo defines an API for Multi-Perspective Issuance Corroboration (MPIC) services to facilitate domain control validation (DCV) from multiple network perspectives. MPIC enhances the security of publicly-trusted certificate issuance by mitigating the risk of localized, equally-specific BGP hijacking attacks that can undermine traditional DCV methods permitted by the CA/Browser Forum Baseline Requirements for TLS Server Certificates. This API enables Certification Authorities (CAs) to more reliably integrate with external MPIC providers, promoting a more robust and resilient Web PKI ecosystem. The API design prioritizes flexibility, scalability, and interoperability, allowing for diverse implementations and deployment models. This standardization effort is driven by the need to consistently address vulnerabilities in the domain validation process highlighted by recent research and real-world attacks, as reflected in Ballot SC-067 V3 of the CA/Browser Forum's Server Certificate Working Group. |
| | Efficient Updates to Messaging Layer Security GroupContext Extension |
| |
|
The Messaging Layer Security (MLS) protocol allows the members of the group to agree on a set of GroupContext extensions. MLS includes a mechanism to do a wholesale replacements of all GroupContext extensions, but not to modify individual extensions. In this document, we define a mechanism that allows implementations to add, update, and remove each element of the GroupContext individually. This also makes it practical for applications using MLS to exploit this feature of MLS to ensure that the group members are in agreement on the state of the application in addition to MLS-related state. |
| | Multi-Perspective Issuance Corroboration (MPIC) Service |
| |
|
This memo defines an API for Multi-Perspective Issuance Corroboration (MPIC) services to facilitate domain control validation (DCV) from multiple network perspectives. MPIC enhances the security of publicly-trusted certificate issuance by mitigating the risk of localized, equally-specific BGP hijacking attacks that can undermine traditional DCV methods permitted by the CA/Browser Forum Baseline Requirements for TLS Server Certificates. This API enables Certification Authorities (CAs) to more reliably integrate with external MPIC providers, promoting a more robust and resilient Web PKI ecosystem. The API design prioritizes flexibility, scalability, and interoperability, allowing for diverse implementations and deployment models. This standardization effort is driven by the need to consistently address vulnerabilities in the domain validation process highlighted by recent research and real-world attacks, as reflected in Ballot SC-067 V3 of the CA/Browser Forum's Server Certificate Working Group. |
| | Composite Token Claims |
| |
|
Composition claims are CBOR Web Token claims that define logical relationships between sets of claims and provide for private claim values via encryption. |
| | SPACE - Scalable Pubsub,Asymmetric and CachEd transport for Deep Space communications |
| |
|
Deep Space communications can be benefited by a publish/subscribe, store-and-forward and asymmetric delivery network over IP that allows communications across links with high latencies and dynamic network conditions (losses and high bit error rates). This specification proposes to use Media over QUIC Transport (MOQT) [MoQTransport] as the common delivery protocol for deep space communications. |
| | Data Unit Groups for DetNet-Enabled Networks |
| |
|
This document provides the description of an Internet Protocol (IP) Version 6 (IPv6) extension header allowing DetNet routers to determine the relative importance between packets of the same flow, which enables gracefully dropping packets in case of congestion. This behaviour can for example be useful for media flows, where different application units can have very different impact on the quality of experience of the user. This document aims primarily at extending the DetNet IP Data Plane in an initial revision of this draft, and may be extended to Multi-Protocol Label Switching (MPLS) and MPLS over User Datagram Protocol (UDP)/IP data plane options in future revisions. |
| | MoQ Chat |
| |
|
MoQ Chat (moq-chat) is a simple text based protocol for exercising MoQ Transport. |
| | Robots Exclusion Protocol Extension to manage AI content use |
| |
|
This document extends RFC9309 by specifying additional rules for controlling usage of the content in the field of Artificial Intelligence (AI). |
| | Green Networking Metrics for Environmentally Sustainable Networking |
| |
| | draft-cx-green-green-metrics-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Alexander Clemm, Carlos Pignataro, Eve Schooler, Laurent Ciavaglia, Ali Rezaki, Greg Mirsky, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document explains the need for network instrumentation that allows to assess a number of sustainability-related attributes such as power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's "greenness" accordingly. Note: This document replaces an earlier document in OPSAWG as the recently-established GREEN provides for a more fitting landing spot. |
| | Ownership and licensing statements in YANG |
| |
| | draft-ietf-opsawg-ol-07.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Eliot Lear, Carsten Bormann |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. |
| | Multipath Support for IGMP/MLD Proxy |
| |
|
This document describes multipath support for Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD) proxy devices. The proposed extension allows IGMP/MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. An upstream interface can be selected on the basis of multiple criteria, such as subscriber information, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. |
| | Remote Posture Assessment for Systems,Containers,and Applications at Scale |
| |
|
This document establishes an architectural pattern whereby a remote attestation could be issued for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to send over individual attestations for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE, and non-TCG defined components will also be included. |
| | Structured Email: Use cases |
| |
|
This document collects and discusses use cases for "structured email" [I-D.ietf-sml-structured-email-02]. |
| | Connected Identity for STIR |
| |
|
The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. |
| | Guidance on RESTful Design for Internet of Things Systems |
| |
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). |
| | Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases |
| |
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". |
| | Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) |
| |
| | draft-ietf-tsvwg-rfc4895-bis-04.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895. |
| |
|
| |
| | SLH-DSA for JOSE and COSE |
| |
| | draft-ietf-cose-sphincs-plus-05.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document describes JOSE and COSE serializations for SLH-DSA, which was derived from SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-205]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/ post-quantum-cryptography) standardization process. |
| | BGP Flowspec for IETF Network Slice Traffic Steering |
| |
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic flow specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be preformed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). |
| | Updates to Anycast Property advertisement for OSPFv2 |
| |
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | An Architecture for a Network Anomaly Detection Framework |
| |
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is generic applicable and extensible. Different applications are being described and exampled with open-source running code. |
| | Flexible Session Protocol |
| |
|
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management |
| | Security Technical Specification for Smart Devices of IoT |
| |
|
With the development of IoT, the security of smart devices has become an important issue for us to discuss. This draft proposes a security framework and detailed requirements in terms of hardware, system, data, network, and management to ensure the security of IoT smart devices. Specifically, hardware security includes the security of hardware interfaces and components. System security encompasses firmware security, security audits, and more. Data security involves data verification and protection of sensitive data.Network security entails stream protection, session security, and more. |
| | Data Transmission Security of Identity Resolution in Industrial Internet |
| |
|
This draft presents a comprehensive overview of the data transmission security within the identity resolution system for the Industrial Internet. Identity resolution systems play a vital role in the Industrial Internet, facilitating secure sharing and intelligent correlation of heterogeneous information across various organizations. This draft focuses on the security services that identity resolution systems should provide during the resolution process. |
| | Artificial Intelligence Framework for Network Management |
| |
|
The adoption of artificial intelligence (AI) in network management (NM) solutions is the way to resolve many of the complex management problems arising from the adoption of NFV and SDN technologies. The AINEMA framework, as discussed in this document, includes the functions, capabilities, and components that MUST be provided by AI modules and models to be successfully applied to NM. This is enhanced by the consideration of seamless integration of different services, including the ability of having multiple AI models working in parallel, as well as the ability of complex reasoning and event processing. In addition, disparate sources of information are put together without increasing complexity, through the definition of a control and management service bus. It allows, for instance, to involve external events in NM operations. Using all available sources of information --- namely, intelligence sources --- allows NM solutions to apply proper intelligence processes that provide explainable results instead of simple AI-based guesses. Such processes are highly based in reasoning and formal and target-based intelligence analysis and decision --- providing evidence-based conclusions and proofs for the decisions --- in the form of AI method outputs with explanations. This will allow computer and network system infrastructures --- and user demands --- to grow in complexity while keeping dependability. Finally, AINEMA has the ability of distributing AI questions among several AI services, potentially from several vendors, in either a recursive or iterative fashion. |
| | Traffic Mapping YANG model for Traffic Engineering (TE) |
| |
|
This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model provides the operator a seamless control and management of which traffic to send on the underlying TE resources. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation Information in the DNS. |
| | Network Proactive Defense based on Source Address Validation |
| |
|
Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. |
| | Aircraft to Anything AdHoc Broadcasts and Session |
| |
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. |
| | Hybrid IANA Registration Policy |
| |
|
The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies. |
| | PFM-SD extension for EVPN multi-homing |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services and in service provider (SP) applications for next-generation virtual private LAN services. EVPN defines sets of procedures to achieve multihoming between peers. When the multicast source is protected by EVPN multihoming for redundancy and multicast receivers are present behind PIM network, there are cases where traffic blackholes. PIM Flooding Mechanism (PFM) and Source Discovery (SD) define new flood mechanisms in PIM domain to carry information about source and group. This draft defines the necessary extension to PFM-SD procedures to have seamless integration with EVPN supported multihoming. |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | LDP Extensions to Support Private Line Emulation (PLE) |
| |
|
This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks. |
| | NASR Use Case and Requirements |
| |
| | draft-liu-nasr-requirements-03.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Peter Liu, Luigi Iannone, Diego Lopez, Antonio Pastor, Meiling Chen, Li Su |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the use cases and requirements that guide the specification of a Network Attestation for Secure Routing framework (NASR). |
| | Identity Assertion Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| | EVPN Group Policy |
| |
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. |
| | Ways to convey the Ratchet Tree in Messaging Layer Security |
| |
|
The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. |
| | Extensible Authentication Protocol (EAP) Using Privacy Pass Token |
| |
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. |
| | Adaptive Routing Framework |
| |
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. |
| | Adaptive Routing Notification for Load-balancing |
| |
|
This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered into the network. |
| | Root CA Certificate Rekeying in the Scenario of Post Quantum Migration |
| |
|
In the public key infrastructures (PKIs), root certifcation authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a one-way link certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the cerficate can be pure PQ ones or hybrid ones. |
| | Semi-Private Messages in the Messaging Layer Security (MLS) Protocol |
| |
|
This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. |
| | Encryption Key Derivation in the COSE using HKDF with SHA-256 |
| |
|
This document specifies the derivation of the content-encryption key in CBOR Object Signing and Encryption (COSE). This mechanism protects against attacks where an attacker manipulates the content- encryption algorithm identifier. |
| | Issue in Route Origin Validation from Route Partial Visibility |
| |
|
In the Resource Public Key Infrastructure (RPKI), validating prefix- origin pairs using Route Origin Authorizations (ROAs) globally and performing Route Origin Validation (ROV) locally at each Autonomous System (AS) with validated ROA payloads (VRPs) can lead to inconsistent results due to partial route visibility. This document highlights how partial route visibility can turn originally non-loose ROAs into loose VRPs, outlines the causes of partial route visibility, and discusses potential solutions to mitigate the issue. |
| | Client Authentication Recommendations for Encrypted DNS |
| |
| | draft-jaked-cared-00.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Tommy Jensen, Jessica Krynitsky, Jeffrey Damick, Matt Engskow, Joe Abley |
| | Working Group: |
Individual Submissions (none) |
|
Some encrypted DNS clients require anonymity from their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols. |
| | Computing Aware Traffic Steering (CATS) with Generic Metric |
| |
|
Steering traffic for computing-related services considering computing resources and circumstances is discussed in CATS WG. Correspondingly, publishing services and updating computing conditions turns out to be a significant issue. It SHOULD be realized that multiple same common metrics are required from both network and service instances in order to evaluate overall performance and further achieve and fulfill appropriate traffic steering and scheduling. Therefore, an implementation for distributed CATS with generic metrics delivery and distribution based on BGP is proposed and discussed in this draft. |
| | Use Cases for IPv6 Network End to End Monitoring |
| |
|
End to end monitoring of IPv6 network is crucial for telecom operator network analysis.This document provides a detailed introduction to the use cases of end to end monitoring in IPv6 network, in order to explore end to end monitoring methods. |
| | SRv6 NET-PGM extension: Compressed BSID Insertion |
| |
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-C-SID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-C-SID flavor. |
| | Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing |
| |
| | draft-akiyama-cmg-00.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Kuon Akiyama, Ryoichi Shinkuma |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics. |
| | SRv6 for Power Grid |
| |
|
This document outlines the deployment of Segment Routing over IPv6 (SRv6) in the power grid communication network, including power grid services, requirement analysis, network structure and different srv6 deployment scenarios. |
| | Advertisement of Multi-Sourced SAV Rules using BGP Link-State |
| |
|
This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rule monitoring and management. |
| | PCEP extensions for Distribution of Link-State and TE Information |
| |
| | draft-ietf-pce-pcep-ls-02.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. |
| | PIM Backup Designated Router Procedure |
| |
| | draft-ietf-pim-bdr-02.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Mankamana Mishra, Anuj Budhiraja, Aravind Paramasivam, Imed Romdhani, Gyan Mishra |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it. |
| | ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets |
| |
|
This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone. |
| | YANG Data Model for Scheduled Attributes |
| |
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
| |
|
| |
| | VPOLL: Consensus Scheduling Component for iCalendar |
| |
|
This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. |
| | A YANG Data Model for Ethernet TE Topology |
| |
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | Egress Peer Engineering using BGP-LU |
| |
| | draft-gredler-idr-bgplu-epe-16.txt |
| | Date: |
14/10/2024 |
| | Authors: |
Hannes Gredler, Kaliraj Vairavakkalai, Chandrasekar R, Balaji Rajagopalan, Ebben Aries, Luyuan Fang |
| | Working Group: |
Individual Submissions (none) |
|
The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links. |
| | Mathematical Mesh 3.0 Part I: Architecture Guide |
| |
|
The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html. |
| | Mathematical Mesh: Reference Implementation |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html. |
| | Mathematical Mesh: Platform Configuration |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html. |
| | A YANG Data Model for Client-layer Tunnel |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. |
| | DNS Web Service Discovery |
| |
|
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html. |
| | Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. |
| |
|
This document describes the underlying naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. For convenience, UDFs are typically presented to the user in the form of a Base32 encoded string. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. |
| | Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE) |
| |
|
This document describes the Data At Rest Encryption (DARE) Envelope and Sequence syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Sequence syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Sequences may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html. |
| | Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms |
| |
|
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the Mesh. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- cryptography.html. |
| | Mathematical Mesh 3.0 Part V: Protocol Reference |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. |
| | Mathematical Mesh 3.0 Part IV: Schema Reference |
| |
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. |
| | Mathematical Mesh 3.0 Part XI: Mesh Presence Service |
| |
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Technical Requirements for Secure Access and Management of IoT Smart Terminals |
| |
|
It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. |
| | Open Service Access Protocol for IoT Smart Devices |
| |
|
With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. |
| | Mathematical Mesh 3.0 Part VII: Mesh Callsign Service |
| |
|
The Mesh Callsign Registry is a name registry that provides a mapping from human-friendly callsigns to root of trusts and a service assigned by the callsign holder to service the account bound to that callsign. An append only sequence authenticated by means of a Merkle Tree and periodic third party notarizations provides ground truth for the integrity of the registry and for all the assertions enrolled in the sequence. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Mathematical Mesh 3.0 Part VI: Reliable User Datagram |
| |
|
A presentation layer suitable for use in conjunction with HTTP and UDP transports is described. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | BGP-LS extensions for BIER-TE |
| |
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. |
| | Segment Routing in Two Dimensional IP Routing |
| |
|
Segment Routing (SR) allows a headend node to steer traffic into a Segment Routing Policy (SR Policy), which represents the routing path by matching the destination address and the corresponding Binding Segment Identifier (BSID). However, determining the target SR Policy only based on destination aspect is incapable for demands for higher dimensional routing. Two Dimensional IP (TwoD-IP) routing is an Internet routing architecture that makes forwarding decisions based on source and destination addresses. TwoD-IP routing can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to the higher dimensional routing. In this document, we extend SR to support TwoD-IP routing, illustrate some typical scenarios of SR with TwoD-IP routing to express the advantage of extending SR to support TwoD-IP routing, and describe the mechanism of how TwoD IP routing protocol cooperates with SR. |
| | Mathematical Mesh 3.0 Part X: Everything |
| |
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Mathematical Mesh 3.0 Part IX: Mesh Notarized Signatures |
| |
|
Creation and verification of Mesh Notarized Signatures is described . A notarized signature is a signature whose time of creation is attested by one or more parties in addition to the signer. In the case of Mesh Notarized Signatures, the attesting parties is the set of all parties participating in a Notarization Mesh. This ideally includes the relying parties. Each participant in a Notarization Mesh maintains their own notary log in the form of a DARE sequence authenticated by a Merkle tree. Participants periodically cross notarize their personal notary log with those maintained by other parties. A Mesh Notarized Signature is bound in time as having being created after time T1 by including one or more sequence apex values as signed attributes. A Mesh Notarized Signature is bound in time as having being created before time T2 by enrolling it in the signer's personal notarization log and engaging in cross-notarization with a sufficient number of Notarization Mesh participants to establish the desired proof. Defection is controlled through an accountability model. If a trusted notary produces multiple inconsistent signed cross Notarization tokens, this provides non-repudiable evidence of a default. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . |
| | Cycle Mapping Learning Method for Scaling DetNet |
| |
|
The scaling DetNet (Deterministic Networking) technology based on cyclic queuing and scheduling is expected to solve the scalability problem of DetNet. One of the key technologies is to accurately obtain the cyclic mapping relationship between adjacent nodes and the packets can achieve the end-to-end deterministic forwarding. This draft describes the method for nodes to learn the cycle mapping relationship through sending learning messages. |
| | PREOF IOAM Method for Deterministic Network Service Sub-layer |
| |
|
This document proposes an active IOAM method to PREOF monitor and troubleshoot for Deterministic Networking (DetNet) in its service sub-layer. The method uses a special PREOF-TRACE message to collect multiple types of information from the target flow's PREOF entities and to record them in the packet, and uses a PREOF-RESPONCE message to feed them back to the head node. It assists the DetNet to monitor and maintain the PREOF for the traffic flow. |
| | Requirements for Host-to-Network Collaboration Signaling |
| |
| | draft-kwbdgrr-tsvwg-net-collab-rqmts-04.txt |
| | Date: |
14/10/2024 |
| | Authors: |
John Kaippallimalil, Dan Wing, Sri Gundavelli, Sridharan Rajagopalan, Spencer Dawkins, Mohamed Boucadair |
| | Working Group: |
Individual Submissions (none) |
|
Collaborative signaling from host-to-network (i.e., client-to-network and server-to-network) can improve the user experience by informing the network about the nature and relative importance of packets (frames, streams, etc.) without having to disclose the content of the packets. Moreover, the collaborative signaling may be enabled so that clients and servers are aware of the network's treatment of incoming packets. Also, client-to-network collaboration can be put in place without revealing the identity of the remote servers. This collaboration allows for differentiated services at the network (e.g., packet discard preference), the sender (e.g., adaptive transmission), or through cooperation of server/client and the network. This document lists some use cases that illustrate the need for a mechanism to share metadata and outlines host-to-network requirements. The document focuses on signaling information about a UDP transport flow (UDP 4-tuple). |
| | BGP Community Container Attribute |
| |
|
Route tagging plays an important role in external BGP (RFC4271) relations for communicating various routing policies between peers. It is also a common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities (original, extended or large). This document defines a new flexible Community encoding in a BGP Attribute that enhances what can be accomplished with BGP communities. Three initial use cases for this are flow specification version 2 (FSv2) actions, routing policy distribution (rpd) actions, and wide communities. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. |
| | Energy Metrics For Data Networks |
| |
|
This document defines a set of energy efficiency metrics to assess and optimize the energy consumption of data networks. These metrics enable network administrators and designers to identify opportunities for energy savings, optimize network performance, and reduce the environmental impact of network operations. The proposed metrics Power Consumption per Data Rate (PCDR), Power Usage Effectiveness (PUE), Network Equipment Energy Efficiency (NEEE), and Energy Proportionality Coefficient (EPC). |
| | Resolvers and Servers for DELEG |
| |
|
This document describes the roles of resolvers and servers in the upcoming DELEG protocol. It might be useful to the DELEG WG in working on the protocol. This document will not become an RFC, but the words or ideas might be used in documents from the DELEG WG. |
| | Cross-Domain Cloud and Network Resource Management Data Model |
| |
|
This document proposes extensions to existing YANG models, as well as new YANG models, to enable the management of cross-domain cloud and network resources. The intent is to provide dynamic resource allocation mechanisms that allow services to scale efficiently across multiple cloud environments and edge computing platforms. By defining unified YANG models for both network and cloud domains, this draft addresses challenges in orchestrating and managing resources in a hybrid environment while maintaining interoperability and dynamic scaling. |
| | Publishing boundaries for IPv6 reputation |
| |
|
Applications such as e-mail track the reputation of the hosts that connect to them by IP address. Since the IPv6 address space is so large, a reputation system needs to aggregate the data for the IPs useded by a single entity. This document describes a file format a network operator can use to describe the sizes of the IP prefixes it allocates, for reputation systems to use to determine the aggregation boundaries. It also specifies an addition to the the Routing Policy Specification Language (RPSL) inetnum: class to refer to the location of the boundary file, and a method to sign boundary files. |
| | Transparent Rate Adaptation Indications for Networks (TRAIN) Protocol |
| |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and approximately what that rate limit is. |
| | Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. |
| | Privacy Pass Issuance Protocols with Public Metadata |
| |
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
| | Intra-domain Source Address Validation (SAVNET) Architecture |
| |
|
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way. |