| |
|
| |
| | Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events |
| |
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8106. |
| | IPv6 Node Requirements |
| |
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. |
| | Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| | draft-ietf-ace-edhoc-oscore-profile-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. |
| | Protecting EST Payloads with OSCORE |
| |
| | draft-ietf-ace-coap-est-oscore-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. |
| | Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the authorization server can use for uploading an access token to a resource server on behalf of the client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the authorization server. Third, it defines a method for the ACE framework to enforce bidirectional access control by means of a single access token. Fourth, it amends two of the requirements on profiles of the framework. Finally, it deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads. For such error responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles of ACE defined in RFC 9202, RFC 9203, and RFC 9431. |
| | The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the client's public key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. |
| | 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. |
| | RTP over QUIC (RoQ) |
| |
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). This document also discusses how to leverage state that is already available from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and describes different options for implementing congestion control and rate adaptation for RTP without relying on RTCP feedback. |
| | 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. |
| | Optimizing BFD Authentication |
| |
|
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. |
| | 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. |
| | Multiple Loss Ratio Search |
| |
|
This document proposes extensions to [RFC2544] throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and enhance result repeatability and comparability. The primary reason for extending [RFC2544] is to address the challenges and requirements presented by the evaluation and testing the data planes of software-based networking systems. To give users more freedom, MLRsearch provides additional configuration options such as allowing multiple short trials per load instead of one large trial, tolerating a certain percentage of trial results with higher loss, and supporting the search for multiple goals with varying loss ratios. |
| | 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. |
| | Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
| |
|
Distributed computing is a tool that service providers can use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities aids support of services such as computationally intensive and delay sensitive services. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response times. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to best meet the customer's expectations and deliver the requested service. |
| | 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. |
| | BBR Congestion Control |
| |
| | draft-ietf-ccwg-bbr-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Neal Cardwell, Ian Swett, Joseph Beshay |
| | Working Group: |
Congestion Control Working Group (ccwg) |
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. |
| | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
| |
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition metadata or content as well as request that it invalidate or purge metadata or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| | Additional Parameter sets for HSS/LMS Hash-Based Signatures |
| |
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | A publish-subscribe architecture for the Constrained Application Protocol (CoAP) |
| |
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. |
| | Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| | Observe Notifications as CoAP Multicast Responses |
| |
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. |
| | Key Update for OSCORE (KUDOS) |
| |
|
This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. |
| | CoAP Transport Indication |
| |
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-09.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| | OSCORE-capable Proxies |
| |
|
Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. |
| | Proxy Operations for CoAP Group Communication |
| |
|
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. |
| | Domain Control Validation using DNS |
| |
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) |
| |
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. |
| | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) |
| |
| | draft-ietf-emu-eap-edhoc-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson |
| | Working Group: |
EAP Method Update (emu) |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE to provide security services efficiently encoded in CBOR. This document also provides guidance on authentication and authorization for EAP-EDHOC. |
| | Resumable Uploads for HTTP |
| |
|
HTTP clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. Prior to interruption, part of a representation may have been exchanged. To complete the data transfer of the entire representation, it is often desirable to issue subsequent requests that transfer only the remainder of the representation. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| | Template-Driven HTTP CONNECT Proxying for TCP |
| |
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| | Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 |
| |
|
In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues. |
| | File-Like ICN Collections (FLIC) |
| |
| | draft-irtf-icnrg-flic-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Christian Tschudin, Christopher Wood, Marc Mosko, David Oran |
| | Working Group: |
Information-Centric Networking (icnrg) |
|
This document describes a simple "index table" data structure and its associated Information Centric Networking (ICN) data objects for organizing a set of primitive ICN data objects into a large, File- Like ICN Collection (FLIC). At the core of this collection is a _manifest_ which acts as the collection's root node. The manifest contains an index table with pointers, each pointer being a hash value pointing to either a final data block or another index table node. |
| | 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. |
| | BGP UPDATE for SD-WAN Edge Discovery |
| |
|
The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. |
| | 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. |
| | JSON Proof Token |
| |
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). |
| | JSON Web Proof |
| |
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay. |
| | JSON Proof Algorithms |
| |
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. |
| | Fully-Specified Algorithms for JOSE and COSE |
| |
|
This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. |
| | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) |
| |
| | draft-ietf-lake-authz-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS |
| |
| | draft-ietf-lamps-pq-composite-kem-05.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-KEM is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [RFC9629]. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-14.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of Evidence in Certificate Signing Requests (CSRs) such as PKCS#10 or Certificate Request Message Format (CRMF) payloads which provides an elegant and automatable mechanism for transporting Evidence to a Certification Authority. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). |
| | Composite ML-DSA For use in X.509 Public Key Infrastructure and CMS |
| |
| | draft-ietf-lamps-pq-composite-sigs-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. |
| | 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]. |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| | Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| | 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. |
| | The Messaging Layer Security (MLS) Extensions |
| |
|
This document describes extensions to the Messaging Layer Security (MLS) protocol. 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/mlswg/mls-extensions. |
| | Media over QUIC Transport |
| |
| | draft-ietf-moq-transport-07.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Luke Curley, Kirill Pugin, Suhas Nandakumar, Victor Vasiliev, Ian Swett |
| | Working Group: |
Media Over QUIC (moq) |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | RESTCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET and DELETE operations, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. |
| | External Trace ID for Configuration Tracing |
| |
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS specified in [I-D.ietf-netconf-over-tls13]. |
| | Augmented-by Addition into the IETF-YANG-Library |
| |
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining the entire dependencies between YANG modules, by directly querying the server's YANG module. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| | 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. |
| | YANG Packages |
| |
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. It describes how packages: are represented on a server, can be defined in offline YANG instance data files, and can be used to define the content schema associated with YANG instance data files. |
| | Use Cases and Practices for Intent-Based Networking |
| |
| | draft-kdj-nmrg-ibn-usecases-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Kehan Yao, Danyang Chen, Jaehoon Jeong, Qin WU, Chungang Yang, Luis Contreras, Giuseppe Fioccola |
| | Working Group: |
Network Management (nmrg) |
|
This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learning and general learning are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. |
| | 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. |
| | Carrying NRP Identifier and related information in MPLS Packet |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Multiple NRPs can be created by network operator to meet the diverse requirements of enhanced VPN services. In packet forwarding, some fields in the data packet needs to be used to identify the NRP the packet belongs to, so that the NRP-specific processing can be executed on the packet. This document proposes a mechanism to carry the data plane NRP ID in an MPLS packet to identify the NRP the packet belongs to. The procedure for processing the data plane NRP ID is also specified. |
| | Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management |
| |
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. |
| | 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. |
| | 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: |
Individual Submissions (none) |
|
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. |
| | EVPN Fast Reroute |
| |
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| | 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. |
| | Supporting In-Situ Operations,Administration,and Maintenance Direct Export Using MPLS Network Actions |
| |
|
In-Situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information that can be used to calculate various performance metrics. IOAM Direct Export (IOAM-DEX) is one of the IOAM Option types, in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the on-path operational state, and telemetry information can be collected using IOAM-DEX Option in combination with MNA. |
| | 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. |
| | Protocol Extension Requirements of Generalized IPv6 Tunnel |
| |
|
IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Slicing, Alternate Marking, IOAM, DetNet, APN. However network devices have different capabilities of IPv6 extension header processing which has much effect on the deployment of these features. This document analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. |
| | 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). |
| | SR Policy Group |
| |
| | draft-cheng-spring-sr-policy-group-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Weiqiang Cheng, Jiang Wenying, Changwang Lin, Yuanxiang Qiu, Yawei Zhang, Ran Chen, Yanrong Liang |
| | Working Group: |
Individual Submissions (none) |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR policy and SR Policy Group to provide best practice cases for operators |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than configuration. This document describes the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
| |
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. RFC Editor: Please replace YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. Please remove this note. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. |
| | 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. |
| | BGP SR Policy Extensions for Path Scheduling |
| |
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. However, more and more cases require path scheduling to improve the network availability and resource utilization. This document proposes extensions to BGP SR Policy to indicate the scheduling time of each candidate path(segment list) and its associated attributes. |
| | Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. |
| | 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. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. It expands on RFC 3901 by now suggesting authoritative and recursive resolvers to operate on both IPv4 and IPv6. This document obsoletes RFC3901. (if approved) 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/momoka0122y/draft-dnsop-3901bis. |
| | Automating DNS Delegation Management via DDNS |
| |
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The author (gratefully) accept pull requests. |
| | 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. |
| | System for Cross-domain Identity Management: Definitions,Overview,Concepts,and Requirements |
| |
|
This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. |
| | 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. |
| | Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines a usage of Datagram Transport Layer Security (DTLS) 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP DTLS chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re- authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| | 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. |
| | Security and Privacy Implications of 3GPP AI/ML Networking Studies for 6G |
| |
|
This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) networking. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. |
| | 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. |
| | Constrained Application Protocol (CoAP) over Bundle Protocol (BP) |
| |
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. |
| | 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. |
| | Mobile User Plane Architecture for Distributed Mobility Management |
| |
| | draft-mhkk-dmm-mup-architecture-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Satoru Matsushima, Katsuhiro Horiba, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Jakub Horn |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case due to the DMM requirement, and is suitable for mobile services which require a large IP address space. |
| | 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. |
| | Remote attestation over EDHOC |
| |
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. |
| | Light MLS |
| |
| | draft-kiefer-mls-light-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| | Working Group: |
Individual Submissions (none) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "light clients" that don't undertake these costs. A light client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a light client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| | Self-Clocked Rate Adaptation for Multimedia |
| |
|
This memo describes a congestion control algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and is a hybrid loss- and delay based congestion control that also supports ECN and L4S. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a mobile system simulator using LongTerm Evolution (LTE) and 5G and is shown to achieve both low latency and high video throughput in these scenarios. This specification obsoletes RFC 8298. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. |
| | 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. |
| | Knowledge Graphs for YANG-based Network Management |
| |
|
The success of the YANG language and YANG-based protocols for managing the network has unlocked new opportunities in network analytics. However, the wide heterogeneity of YANG models hinders the consumption and analysis of network data. Besides, data encoding formats and transport protocols will differ depending on the network management protocol supported by the network device. These challenges call for new data management paradigms that facilitate the discovery, understanding, integration and access to silos of heterogenous YANG data, abstracting from the complexities of the network devices. This document introduces the knowledge graph paradigm as a solution to this data management problem, with focus on YANG-based network management. The document provides background on related topics such as ontologies and graph standards, and shares guidelines for implementing knowledge graphs from YANG data. |
| | Bgp Extension for Tunnel Egress Point |
| |
|
In AI networks, flow characteristics often exhibit a low number of flows but with high bandwidth per flow, making it easy to cause network congestion when using traditional flow-level load balancing methods. Currently, the direction of traffic scheduling focuses on load sharing individual packets of the same flow, which requires sorting based on the Tunnel Egress Point information from the remote end. This document describes the method of publishing Tunnel Egress Point through the BGP protocol. |
| | Lightweight Authentication Methods for IP Header |
| |
|
This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. |
| | 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. |
| | EDHOC PSK authentication |
| |
|
This document specifies the Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. It describes the authentication processes, message flows, and security considerations of this authentication method. |
| | Lightweight GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the UDP-based Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP), which is designed to be a lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. LW-GRASP can work reliably over UDP, making it suitable for the IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential way to adapt the LW-GRASP to work on the network without IP connectivity. |
| | SPICE GLUE: GLobal Unique Enterprise Identifiers |
| |
|
This specification defines the glue URI scheme and the rules for encoding these URIs. It also establishes the registries necessary for management of this scheme. |
| | Pacing in Transport Protocols |
| |
| | draft-welzl-iccrg-pacing-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | Extensible Delegation for DNS |
| |
| | draft-wesplaap-deleg-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| | Working Group: |
Individual Submissions (none) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| | 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. |
| | Upper limit values for DNS |
| |
|
There are parameters in the DNS protocol that do not have clear upper limit values. If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks, and several attack methods have been proposed. This draft proposes reasonable upper limit values for DNS protocols. |
| | 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. |
| | Source Address Validation Enhanced by Network Controller |
| |
|
Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. |
| | 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. |
| | Mobile Traffic Steering |
| |
| | draft-liebsch-dmm-mts-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Individual Submissions (none) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | Knowledge Graph Framework for Network Operations |
| |
| | draft-mackey-nmop-kg-for-netops-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Michael Mackey, Benoit Claise, Thomas Graf, Holger Keller, Dan Voyer, Paolo Lucente |
| | Working Group: |
Individual Submissions (none) |
|
This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. 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/mike-mackey. |
| | Using BMP over QUIC connection |
| |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | 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. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | 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. |
| | Post-Handshake Authentication via PAKE for TLS 1.3 |
| |
|
This document provides a mechanism that uses password-authenticated key exchange (PAKE) as a post-handshake authentication for TLS 1.3, and that supports PAKE algorithms negotiation and optional channel binding. |
| | 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). |
| | Populating a list of YANG data nodes using templates |
| |
|
This document presents a modeling technique for configuring large scale devices in a compact way, when the device contains many similar data node patterns. A device here refers to any such entity that acts as a netconf server. This is realized by instructing the device to locally generate repetitive patterns of data nodes from a master copy called 'template' that is configured in the device. This approach is both convenient and efficient, as it minimizes the size of the running data store and reduces network provisioning time. It leverages existing YANG specification features and can be implemented with standard, off-the-shelf tools. |
| | 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). |
| | Automation Scenarios and Requirements for Level 4 Autonomous Networking (AN) |
| |
|
This document describes OTN-WDM service automation and collaboration scenarios in transport networks and defines the functional requirements of domain controller in these scenarios. |
| | 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. |
| | Applying BGP-LS Segment Routing Extensions to BGP-LS SPF |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing (SR) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. In some networks, it may be useful to enable SR based source routing mechanism together with BGP-LS SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for segment routing to the BGP-LS SPF SAFI. |
| | 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. |
| | Serialization of MoQ Objects to Files |
| |
|
This specification provides a way to save the meta data about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the meta data and payload data allow the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to client. |
| | 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. |
| | Calibration of Measured Time Values between Network Elements |
| |
|
Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. This draft proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. |
| | 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. |
| | YANG Data Model for BGP about RPKI |
| |
| | draft-liu-idr-bgp-rpki-yang-00.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 BGP information about Resource Public Key Infrastructure (RPKI). |
| | 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. |
| | Signalling Key State Via DNS EDNS(0) OPT |
| |
|
This document introduces the KeyState EDNS(0) option code, to enable the exchange of SIG(0) key state information between DNS entities via the DNS protocol. The KeyState option allows DNS clients and servers to include key state data in both queries and responses, facilitating mutual awareness of SIG(0) key status between child and parent zones. This mechanism addresses the challenges of maintaining synchronization of SIG(0) keys used for securing DNS UPDATE messages, thereby enhancing the efficiency and reliability of DNS operations that require coordinated key management. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-opt-transaction-state (https://github.com/johanix/draft-berra-dnsop-transaction-state-00). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | 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. |
| | Simple Time Over MoQ Protocol (STOMP) |
| |
|
This document describes Simple Time Over MoQ Protocol (STOMP), a protocol for sending the local time and, optionally, location information via Media Over QUIC Transport (MOQT) protocol [I-D.ietf-moq-transport]. Such information enables observing endpoints to measure latencies and monitor health of MOQT delivery network from different geographical locations. |
| | 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. |
| | A Password Authenticated Key Exchange Extension for TLS 1.3 |
| |
| | draft-bmw-tls-pake13-00.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Laura Bauman, Samir Menon, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. |
| | 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. |
| | YANG-Push Operational Data Observability Enhancements |
| |
|
This early draft proposes some enhancements to YANG-Push to optimize its behavior for operational data telemetry. It also lists some additional issues that could potentially be discussed if there is further interest in this work, in particular whether we should be attempting extensions to YANG-Push (as this document is currently framed) or instead should attempt to define a new 'YANG-Push lite'. |
| | Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness |
| |
|
When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Consequently, they may continue to use addresses which are not valid for that link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC. |
| | 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. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) ) |
| |
|
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based method to authenticate DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. |
| | DHCP Option Concatenation Considerations |
| |
|
DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by [RFC3396]. However, this mechanism is required to be supported for all options. This leads to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences. |
| | 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. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. |
| | 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. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. |
| | An Information Model for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-04.txt |
| | Date: |
21/10/2024 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The primary function of a network is to transport and deliver packets according to service level objectives. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Device-reported packet loss provides the most direct signal for network operations to identify the customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss. |
| | 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. |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The advent of a Cryptographically Relevant Quantum Computer (CRQC) would render state-of-the-art, traditional public-key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both classical and quantum attacks. This document explains why engineers need to be aware of and understand post- quantum cryptography, detailing the impact of CRQCs on existing systems and the challenges involved in transitioning. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. |
| | qlog: Structured Logging for Network Protocols |
| |
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| | QUIC event definitions for qlog |
| |
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| | HTTP/3 qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| | Multipath Extension for QUIC |
| |
| | draft-ietf-quic-multipath-11.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/multipath. |
| | (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS |
| |
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| | 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. |
| | Destination/Source Routing |
| |
|
This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously. |
| | Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) |
| |
| | draft-ietf-sidrops-bar-sav-05.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery |
| | Working Group: |
Source Address Validation in Intra-domain and Inter-domain Networks (savnet) |
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-03.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| | Human Readable Validate ROA Payload Notation |
| |
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| | Human Readable ASPA Notation |
| |
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| | Structured Email: Use cases |
| |
|
This document collects and discusses use cases for "structured email" [I-D.ietf-sml-structured-email-02]. |
| | Segment Routing IPv6 Security Considerations |
| |
| | draft-ietf-spring-srv6-security-01.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Nick Buraglio, Tal Mizrahi, tongtian124, Luis Contreras, Fernando Gont |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| | 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. |
| | Secure Reporting of Update Status |
| |
| | draft-ietf-suit-report-10.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| | Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests |
| |
| | draft-ietf-suit-mti-08.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Brendan Moran, Oyvind Ronningstad, Akira Tsukamoto |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
This document specifies algorithm profiles for SUIT manifest parsers and authors to ensure better interoperability. These profiles apply specifically to a constrained node software update use case. |
| | 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). |
| | Scalability Considerations for Network Resource Partition |
| |
| | draft-ietf-teas-nrp-scalability-06.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| | IETF Network Slice Controller and its Associated Data Models |
| |
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. |
| | 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". |
| | Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings |
| |
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. |
| | SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH) |
| |
|
This document specifies an extension to the SSLKEYLOGFILE format to support the logging of information about Encrypted Client Hello (ECH) related secrets. Two new labels are introduced, namely ECH_SECRET and ECH_CONFIG, which log the Hybrid Public Key Encryption (HPKE)- derived shared secret and the ECHConfig used for the ECH, respectively. This extension aims to facilitate debugging of TLS connections employing ECH. |
| | 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. |
| | 464XLAT Customer-side Translator (CLAT): Node Recommendations |
| |
|
464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions. |
| | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. |
| | WebTransport over HTTP/3 |
| |
|
WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. |
| | WebTransport over HTTP/2 |
| |
| | draft-ietf-webtrans-http2-10.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie |
| | Working Group: |
WebTransport (webtrans) |
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. |
| | Workload Identity in a Multi System Environment (WIMSE) Architecture |
| |
| | draft-ietf-wimse-arch-02.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |
| |
|
| |
| | Transmission of IPv6 Packets over Short-Range Optical Wireless Communications |
| |
| | draft-ietf-6lo-owc-02.txt |
| | Date: |
20/10/2024 |
| | Authors: |
Younghwan Choi, Cheol-min Kim, Carles Gomez |
| | Working Group: |
IPv6 over Networks of Resource-constrained Nodes (6lo) |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| | 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. |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also briefly mentioned. Reference topologies for evaluation of the solutions are given as well. |
| | Definition For New BMP Statistics Type |
| |
|
RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router. This document updates RFC 7854 by adding new statistics type to monitor BMP rib-in and rib- out Ribs. |
| | CCNx Content Object Chunking |
| |
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. |
| | 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). |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and a list of DNS zones that are accessible via a proxy. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. |
| | 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. |
| | Proxying Ethernet in HTTP |
| |
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. |
| | 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. |
| | Blind BBS Signatures |
| |
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. 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/BasileiosKal/blind-bbs-signatures. |
| | 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]. |
| | End-to-End Secure Objects for Media over QUIC Transport |
| |
|
This document describes an end-to-end authenticated encryption scheme for application objects intended to be delivered over Media over QUIC Transport (MOQT). We reuse the SFrame scheme for authenticated encryption of media objects, while suppressing data that would be redundant between SFrame and MOQT, for an efficient on-the-wire representation. |
| | 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. |
| | IGP-based Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) |
| |
|
This document proposes a new IGP-based intra-domain source address validation (SAV) solution, called IGP-SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows intra- domain routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra-domain routing protocol. By using SAV-specific information, intra-domain routers can generate and update accurate SAV rules in an automatic way. |
| | 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. |
| | Source Prefix Advertisement for Intra-domain SAVNET |
| |
|
This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. SPA- based SAVNET allows routers in an intra-domain network to exchange SAV-specific information through SPA messages. Compared with existing intra-domain SAV mechanisms RFC2827 [RFC3704], SPA-based SAVNET can generate more accurate and robust SAV rules on intra- domain routers in an automatic way. This document introduces the content of SPA messages and the process of generating SAV rules. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document. |
| | 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. |
| | Network Attestation for Secure Routing (NASR) Architecture |
| |
|
This document provides an architecture overview of NASR entities, interactive procedures and messages. |
| | 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. |
| | AI based Network Management Agent(NMA): Concepts and Architecture |
| |
|
With the development of AI(Artificial Intelligence) technology, large model have shown significant advantages and great potential in recognition, understanding, decision-making, and generation, and can well match the self-intelligent network management requirements for the goal of autonomous network[TMF-IG1230] or Intent-based Networking [RFC9315], and can be used as one of the potential driving technologies to drive high-level autonomous networks. When introducing AI for network management, how to integrate AI technology and deal with the relationship with the existing network management entity (such as network controller) is the focus of research and standardization. This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the delpoyment mode of NMA, and proposes the comman processing flow and typical application scenarios of NMA. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | 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. |
| | BBS per Verifier Linkability |
| |
|
The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. |
| | 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. |
| | SR based Loop-free implementation |
| |
|
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
|
This document describes an approach where ACME Client can prove possession of a Remote Attestation Result to an ACME Server. |
| | 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. |
| | Traffic Engineering (TE) and Service Mapping YANG Data Model |
| |
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. |
| | 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. |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile and ciphersuite requirements. |
| | The JSON format for vCon - Conversation Data Container |
| |
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) |