| |
|
| |
| | CDNI Edge Control Metadata |
| |
|
This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. |
| | 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. |
| | 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. |
| | IANA Registry for the First Nibble Following a Label Stack |
| |
| | draft-ietf-mpls-1stnibble-05.txt |
| | Date: |
24/04/2024 |
| | Authors: |
Kireeti Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
The goal of this memo is to create a new IANA registry (called the Post-stack First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. The memo offers a rationale for such a registry, describes how the registry should be managed, and provides some initial entries. Furthermore, this memo sets out some documentation requirements for registering new values. Finally, it provides some recommendations that make processing MPLS packets easier and more robust. The relationship between the IANA IP Version Numbers (RFC 2780) and the Post-stack First Nibble registry is described in this document. This memo, if published, would update RFC 4928. |
| | Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection |
| |
|
This document describes how to use Simple Two-way Active Measurement Protocol (STAMP) test packets in combination with Hybrid Methods to perform Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. It also defines optional TLVs which are carried in STAMP test packets to enhance the STAMP based functions. Such extensions to STAMP enable performance measurement and collection at every node and link along a STAMP test packet's delivery path. |
| | Epoch Markers |
| |
|
This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. |
| | IPFIX Alternate-Marking Information |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | BGP over TLS/TCP |
| |
|
This document specifies the utilization of TCP/TLS to support BGP. |
| | A Profile for Mapping Origin Authorizations (MOAs) |
| |
|
For the authenticity of the mapping origin of IPv4 address block in IPv6-only networks, this document defines a standard profile for Mapping Origin Authorizations (MOAs). MOA is a cryptographically signed object that provides a means of verifying that the holder of a set of IPv4 prefixes has authorized an IPv6 mapping prefix to originate mapping for those prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. |
| | Compressed SRv6 Segment List Encoding |
| |
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SR segment endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 SID list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. |
| | A YANG Data Model for the RFC 9543 Network Slice Service |
| |
|
This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. |
| |
|
| |
| | BGP Color-Aware Routing (CAR) |
| |
|
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and the BGP extensions to enable intent-aware routing. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. |
| | BGP CT - Adaptation to SRv6 dataplane |
| |
|
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document. |
| | More Instant Messaging Interoperability (MIMI) message content |
| |
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| | Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type |
| |
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server of changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server. |
| | 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. |
| | BGP Extension for Distributing CP Threshold Constraints of SR Policy |
| |
|
This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. |
| | EAT profile for Intel® Trust Domain Extensions (TDX) attestation result |
| |
|
Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. |
| | A Mechanism for X.509 Certificate Discovery |
| |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. |
| | Extending ICMP for Node Identification |
| |
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). |
| | 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. |
| | Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values |
| |
|
RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a registry for "IS-IS Neighbor Link-Attribute Bit Values". This document changes the registration procedure for that registry from "Standards Action" to "Expert Review". |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility |
| |
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. |
| | TACACS+ TLS 1.3 |
| |
| | draft-ietf-opsawg-tacacs-tls13-07.txt |
| | Date: |
23/04/2024 |
| | Authors: |
Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC RFC8907. |
| |
|
| |
| | VPOLL: Consensus Scheduling Component for iCalendar |
| |
|
This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. |
| | A YANG Data Model for 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. |
| | Related Certificates for Use in Multiple Authentications within a Protocol |
| |
|
This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-15.txt |
| | Date: |
22/04/2024 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. |
| | LISP Geo-Coordinate Use-Cases |
| |
|
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. Some use-cases can be geo-fencing and physically locating objects. |
| | IGP Unreachable Prefix Announcement |
| |
|
In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. |
| | Requirements for Solutions that Support MPLS Network Actions (MNA) |
| |
|
This document specifies requirements for the development of MPLS Network Actions (MNA) which affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER). |
| | Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes |
| |
|
Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. Path Segment can be used in an SR over MPLS (SR-MPLS) data plane. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV and sub-TLV definitions for PSID. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | Explicit Congestion Notification for the Stream Control Transmission Protocol |
| |
|
This document describes the addition of the Explicit Congestion Notification (ECN) to the Stream Control Transmission Protocol (SCTP). |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
| |
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| | Basic Support for IPv6 Networks Operating over 5G Vehicle-to-Everything Communications |
| |
|
This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to the existing IPv6 protocol stack. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 in more complex 5G scenarios are not covered in this specification and are a subject for future work. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | BGP SPF Extensions for Intra-domain SAVNET |
| |
|
This document describes the BGP SPF protocol extension that is required for Source Address Validation in Intra-domain. By extending BGP SPF and adding the BGP SPF protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification. |
| | Service Interworking between SRv6 |
| |
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
| |
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| | A YANG Data Model for Network Incident Management |
| |
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics and other anomaly information can be aggregated into few amount of network incidents by data correlation analysis and the service impact analysis. This document defines YANG Modules for the network incident lifecycle management. The YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of network service health and root cause analysis. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with ECDH,ML-KEM,and FrodoKE |
| |
|
RFC 9370 specifies a framework that supports mulitple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additiona KEMs employed with the oringal ECDH to derive the final shared secret keys for IPsec protocols. The primitive goal is to mitigate the security threat against quantum computers when additional post-quantum (PQ) KEMs are hybrided with the orinigal ECDH key exchange. This draft describes concretely how two specific QP KEMs, namely, ML-KEM and FrodoKEM, can be instantiated in the IKEv2 as the additional KEMs with the main ECDH to achieve hybrid key agreement. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, when considering the code points for ML-KEM has been considered in [I-D.D24]. ] |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
| |
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. |
| | Internet Group Management Protocol,Version 3 |
| |
|
This document specifies a revised Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 3376. |
| | IANA Considerations for Internet Group Management Protocols |
| |
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and updates RFC 4443. |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-08.txt |
| | Date: |
22/04/2024 |
| | Authors: |
Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections. It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are stored, allowing them to be later used to modify the congestion control behavior of a subsequent connection. It describes assumptions and defines requirements for how a sender utilizes these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilize available capacity. It discusses how use of the method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Ping Enabled IOAM Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| | Delay-based Metric Extension for the Babel Routing Protocol |
| |
|
This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower latency links over higher latency ones. |
| | Constrained Resource Identifiers |
| |
| | draft-ietf-core-href-15.txt |
| | Date: |
21/04/2024 |
| | Authors: |
Carsten Bormann, Henk Birkholz |
| | Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –15 of this draft continues -14 by picking up // more comments, such as moving to a CRI scheme number registration // system based on unsigned numbers. This revision still contains // open issues and is intended to serve as a snapshot. |
| | Structured Field Values for HTTP |
| |
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document obsoletes RFC 8941. |
| | LISP Map Server Reliable Transport |
| |
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| | Generic Multicast Router Election on LAN's |
| |
|
When a host is connected to multiple multicast capable routers, each of these routers is a candidate to process the multicast flow for that LAN, but only one router should be elected to process it. This document proposes a generic multicast router election mechanism using Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) that can be used by any Multicast Overlay Signalling Protocol (MOSP). Having such generic election mechanism removes a dependency on Protocol Independent Multicast (PIM). |
| | Security for the NFSv4 Protocols |
| |
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the ACL feature, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881, |
| | A Collaborative Framework for Cyberspace Governance: the Internet of Governance |
| |
|
This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples. |
| | EAT Attestation Results |
| |
| | draft-fv-rats-ear-03.txt |
| | Date: |
21/04/2024 |
| | Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| | Integration of Speech Codec Enhancement Methods into the Opus Codec |
| |
|
This document proposes a method for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| | Resource Guarantee for SRv6 Policies |
| |
|
This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list , the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. |
| | An Application Layer Interface for Non-IP device control (NIPC) |
| |
| | draft-brinckman-nipc-01.txt |
| | Date: |
21/04/2024 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | IGP Color-Aware Routing |
| |
| | draft-lin-lsr-igp-car-01.txt |
| | Date: |
21/04/2024 |
| | Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| | Static Context Header Compression and Fragmentation for Zero Energy Devices |
| |
|
This document describes the use of SCHC for very constraint devices. The use of SCHC will bring connectivity to devices with restrained use of battery and long delays. |
| | OAuth 2.0 Security Best Current Practice |
| |
|
This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFC 6749, RFC 6750, and RFC 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. It further deprecates some modes of operation that are deemed less secure or even insecure. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines a new method of client authentication for OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme. |
| | Private Line Emulation over Packet Switched Networks |
| |
| | draft-ietf-pals-ple-04.txt |
| | Date: |
21/04/2024 |
| | Authors: |
Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Chris Brown |
| | Working Group: |
Pseudowire And LDP-enabled Services (pals) |
|
This document describes a method for encapsulating high-speed bit- streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency. |
| |
|
| |
| | Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. |
| | A YANG Data Model for Optical Transport Network Topology |
| |
| | draft-ietf-ccamp-otn-topo-yang-18.txt |
| | Date: |
19/04/2024 |
| | Authors: |
Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. This model enables clients, which interact with a transport domain controller, for OTN topology-related operations such as obtaining the relevant topology resource information. |
| | Constrained Application Protocol (CoAP) Performance Measurement Option |
| |
| | draft-ietf-core-coap-pm-02.txt |
| | Date: |
19/04/2024 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Massimo Nilo, Fabrizio Milan, Fabio Bulgarella |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. |
| | BGP SR Policy Extensions to Enable IFIT |
| |
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. |
| | Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS) |
| |
|
This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or part of a key derivation function. |
| | Flexible Algorithms: Bandwidth,Delay,Metrics and Constraints |
| |
|
Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. |
| | TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences |
| |
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as- a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology in the way that it makes content distribution more accessible to more people by dramatically reducing the costs of replication. |
| | 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 |
| | Using NETCONF over QUIC connection |
| |
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF can be carried over various transports such as TCP, SSH or else. QUIC provides useful semantics for Network management and NETCONF in particular as a single connection can carry multiple requests over streams, enabling much better efficiency and performance for both peers. QUIC provides shorter handshake and includes TLS. QUIC is also more adaptable to more difficult environments such as those with long delays. This document describes how to use NETCONF over the QUIC transport protocol, named NETCONFoQUIC. |
| | EDNS Presentation and JSON Format |
| |
|
This document describes the textual and JSON representation formats of EDNS options. It also modifies the escaping rules of the JSON representation of DNS messages, previously defined in RFC8427. |
| | Coordinated Congestion Management |
| |
|
AI fabric is sensitive to bandwidth. Congestion management, including congestion control and load balancing, is a main method to fully utilize network resource. However, current congestion management mechanisms are not coordinated, which lead to throughput decreasing. This document provides a scheme to coordinate different congestion management mechanisms. It describes the design principle, behaviors of network switches and hosts in the scheme, and gives an example to show end-to-end procedure. |
| | 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 beyond RFC3901 in so far that it now suggests authoritative and iterative resolvers to operate on both IPv4 and IPv6. This document obsoletes RFC 3901. (if approved) |
| | OpenPGP Hardware-Backed Secret Keys |
| |
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored on a hardware device. |
| | OAuth Status Attestations |
| |
|
Status Attestation is a signed object that demonstrates the validity status of a digital credential. These attestations are periodically provided to holders, who can present these to Verifiers along with the corresponding digital credentials. The approach outlined in this document makes the verifiers able to check the non-revocation of a digital credential without requiring to query any third-party entities. |
| | OAM for use in GENEVE |
| |
| | draft-ietf-nvo3-geneve-oam-10.txt |
| | Date: |
19/04/2024 |
| | Authors: |
Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. |
| | A Common YANG Data Model for Attachment Circuits |
| |
| | draft-ietf-opsawg-teas-common-ac-10.txt |
| | Date: |
19/04/2024 |
| | Authors: |
Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. |
| | YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) |
| |
|
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. |
| | A Network YANG Data Model for Attachment Circuits |
| |
|
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in I-D.ietf-opsawg-teas- attachment-circuit. The module augments the 'ietf-network' and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). |
| | An RDAP Extension for Geofeed Data |
| |
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and link relation type for the associated link objects included in responses. |
| | RPKI Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| | 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". |
| | New Protocols Must Require TLS 1.3 |
| |
|
TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Since TLS 1.3 use is widespread, new protocols must require and assume its existence. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |
| |
|
| |
| | Discovery for BRSKI 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. |
| | Task Extensions to iCalendar |
| |
|
This document updates and defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. |
| | CDNI Capacity Capability Advertisement Extensions |
| |
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document supplements the CDNI Capability Objects defined in RFC 8008. |
| | 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. |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. |
| | BGP Extension for 5G Edge Service Metadata |
| |
|
This draft describes a new Metadata Path Attribute and some Sub-TLVs for egress routers to advertise the Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE). |
| | Announcing Supported Authentication Methods in IKEv2 |
| |
|
This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different type to authenticate each other. |
| | mLDP Extensions for Multi-Topology Routing |
| |
|
Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP (Multipoint label distribution protocol) in a network that supports MTR and/or FA, mLDP is required to become topology and FA aware. This document specifies extensions to mLDP to support MTR with FA such that when building a Multipoint LSPs(Label Switched Paths) it can follow a particular topology and algorithm. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. |
| | ISP Dual Queue Networking Deployment Recommendations |
| |
|
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment decisions are ultimately left to implementers. This document explores the potential implications of key deployment decisions and makes recommendations for those decisions that may help drive adoption. |
| | 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. |
| | Enforcing end-to-end delay bounds via queue resizing |
| |
|
This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. |
| | Ethernet VPN Signalling Extensions for Bit-stream VPWS |
| |
|
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). |
| | 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. |
| | Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers |
| |
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing node as well as workflows of CATS procedures. This document describes various threats and security concerns related to CATS networks and existing approaches to solve these threats. |
| | Representing metadata annotations in YANG-CBOR |
| |
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| | Ownership and licensing statements in YANG |
| |
| | draft-ietf-opsawg-ol-05.txt |
| | Date: |
18/04/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. |
| | (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. |
| | The "xml2rfc" version 3 Vocabulary as Implemented |
| |
|
This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home pags at . Source code and issues list for this draft can be found at . |
| | Detailed Software Supply Chain Uses Cases for SCITT |
| |
| | draft-ietf-scitt-software-use-cases-03.txt |
| | Date: |
18/04/2024 |
| | Authors: |
Henk Birkholz, Yogesh Deshpande, Dick Brooks, Bob Martin, Brian Knight |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document includes a collection of representative Software Supply Chain Use Cases. These use cases aim to identify software supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. |
| | Circuit Style Segment Routing Policies |
| |
| | draft-ietf-spring-cs-sr-policy-02.txt |
| | Date: |
18/04/2024 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). |
| | Workload Identity in a Multi System Environment (WIMSE) Architecture |
| |
| | draft-ietf-wimse-arch-00.txt |
| | Date: |
18/04/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. |
| |
|
| |
| | JMAP Sharing |
| |
|
This document specifies a data model for sharing data between users using JMAP. Future documents can reference this document when defining data types to support a consistent model of sharing. |
| | 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. |
| | HESP - High Efficiency Streaming Protocol |
| |
| | draft-theo-hesp-06.txt |
| | Date: |
17/04/2024 |
| | Authors: |
Pieter-Jan Speelmans |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a protocol for delivering multimedia data, enabling ultra-low latency and fast channel change over HTTP networks. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 2 of this protocol. |
| | Interconnecting domains with IBGP |
| |
|
This document relaxes the recommendations specified in [RFC4364] and [RFC4456] allowing the building of Inter-domain L3VPN architecture with internal BGP. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| | BGP Operations for Inter-domain SAV |
| |
|
This document attempts to present deployment considerations of source address validation using BGP protocol in inter-domain network. |
| | BGP Flow Specification Version 2 - IP Basic |
| |
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. IDR requires two implementations prior to standardization. Implementers feedback on FSv2 was that the complete FSv2 has the contains the correct information, but that breaking FSv2 into a progression of documents would be helpful. The first priority in this progression is expanded IP DDOS capabilities. This document contains original FSv2 IP DDOS capabilities in FlowSpec v2 using just the extended communities to define actions. |
| | A Method for Exploring Latency Correlation in Multipath Networks |
| |
|
The exploration of latency correlation patterns is of great significance for characterizing network states. However, existing measurement approaches have to confront multiple challenges in detecting latency correlation factors, such as probing speed, routing hops and geographical locations. In this paper, we conduct three tasks to handle these issues. The first is to construct relative latency measurement strategies for individual machines without any time synchronization and control plane requirements. The probing speed has been increased by 14.3% in the same hardware conditions. In 4G/5G heterogeneous edges enabled by different mobile operators, worldwide 5003 target servers are selected to acquire more than 1TB network datasets. The second is to reveal the potential modes between latency and routing hops. Surprisingly, 91.2% available targets present non-positive characteristics in extreme cases. The third is to analyze the fine-grained relationship between latency and geographical locations. We found that the significance of mean backward receiving delay is higher than other parameters, with a maximum of 33%. Finally, we also made optimizations regarding latency compression and time accuracy in multipath networks. The experimental data have been released to an open-source community for further investigations. |
| | Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry |
| |
|
This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. |
| | Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane |
| |
| | draft-ietf-spring-bfd-10.txt |
| | Date: |
17/04/2024 |
| | Authors: |
Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, Jiang Wenying |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path (LSP) Ping to bootstrap a BFD session, optional control of the selection of a segment list as the reverse direction of the BFD session, applicability of BFD Demand mode, and Seamless BFD in the SR-MPLS domain. Also, the document describes the use of the BFD Echo function with the BFD Control packet payload. |
| | Compact TLS 1.3 |
| |
| | draft-ietf-tls-ctls-10.txt |
| | Date: |
17/04/2024 |
| | Authors: |
Eric Rescorla, Richard Barnes, Hannes Tschofenig, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. |
| |
|
| |
| | IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription |
| |
|
This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address; the document updates RPL (RFC 6550, RFC 6553) to add a new Non-Storing Multicast Mode and a new support for anycast addresses in Storing and Non-Storing Modes. This document extends RFC 9010 to enable the 6LR to inject the anycast and multicast addresses in RPL. |
| | Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security |
| |
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations. |
| | Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) |
| |
|
Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct the egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system to request that the remote BFD peer transmits BFD control packets over the specified LSP. |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines a common schedule YANG module which is designed to be applicable for scheduling information such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings. |
| | 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. |
| | SPKI S-Expressions |
| |
| | draft-rivest-sexp-06.txt |
| | Date: |
16/04/2024 |
| | Authors: |
Ronald Rivest, Donald Eastlake |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies a data structure representation that is suitable for representing arbitrary, complex data structures. It was devised in 1996/1997 to support SPKI (RFC 2692) certificates with the intent that it be more widely spplicable and has been used elsewhere. There are many implementations in a variety of languages. Uses of this representation herein are referred to as "S-expressions". This memo make precise the encodings of these S-expressions: it gives a "canonical form" for them, describes two "transport" representations, and also describe an "advanced" format for display to people. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | Securing service-to-service traffic by WIMSE Token |
| |
|
This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens. |
| | Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects |
| |
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. |
| | Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values |
| |
|
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-ttl-extension. |
| | RIFT Applicability |
| |
| | draft-ietf-rift-applicability-14.txt |
| | Date: |
16/04/2024 |
| | Authors: |
Yuehua Wei, Zheng Zhang, Dmitry Afanasiev, Pascal Thubert, Tony Przygienda |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document discusses the properties, applicability and operational considerations of RIFT in different network scenarios. It intends to provide a rough guide how RIFT can be deployed to simplify routing operations in Clos topologies and their variations. |
| | On the use of the CMS signing-time attribute in RPKI Signed Objects |
| |
|
In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. Signed Objects contain a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols. This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute. |
| | 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. |
| |
|
| |
| | BGP Dissemination of L2 Flow Specification Rules |
| |
|
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. |
| | X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs |
| |
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-21.txt |
| | Date: |
15/04/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). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | LISP Distinguished Name Encoding |
| |
|
This draft defines how to use the AFI=17 Distinguished Names in LISP. |
| | Binary Uniform Language Kit 1.0 |
| |
|
This specification describes a uniform, decentrally extensible and efficient format for data serialization. |
| | Just because it's an Internet-Draft doesn't mean anything... at all... |
| |
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| | SSH Agent Protocol |
| |
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. |
| | LISP Data-Plane Telemetry |
| |
|
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. |
| | Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX |
| |
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. |
| | Performance Measurement for Geneve |
| |
|
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
| | 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. |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Forward Error Correction (FEC) for SCHC framework |
| |
|
This document describes a Forward Error Correction (FEC) method that is applied over the SCHC framework to improve the network performance under certain range of loss/error rates. |
| | A File Format to Aid in Consumer Privacy Enforcement,Research,and Tools |
| |
| | draft-colwell-privacy-txt-00.txt |
| | Date: |
15/04/2024 |
| | Authors: |
Nick Sullivan, Louise Van der Peet, Georgios Smaragdakis, Brien Colwell |
| | Working Group: |
Individual Submissions (none) |
|
This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txt // https://datatracker.ietf.org/doc/html/rfc9309, security.txt // https://datatracker.ietf.org/doc/html/rfc9116, or ads.txt // https://iabtechlab.com/ads-txt/, in the / directory or /.well- known directory. The file format adds structured data for three areas: 1. A machine parsable and complete privacy policy 2. Consumer actions under their privacy rights 3. Cookie disclosures |
| | Double Nonce Derive Key AES-GCM (DNDK-GCM) |
| |
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM) that operates with a 32- byte root key and encrypts with a 24-byte random nonce, and optionally provides for key commitment. Encryption takes the root key and a random nonce, derives a fresh encryption key and a key commitment value, invokes AES-GCM with the derived key and a 12-byte zero nonce, and outputs the ciphertext, authentication tag and the key commitment value. The low collision probability with 24-byte random nonces extends the lifetime of the root key and this supports processing up to 2^64 bytes under one root key. DNDK-GCM involves a small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption on AES as a pseudorandom permutation. |
| | Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. |
| | Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices |
| |
|
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. |
| |
|
| |
| | Support of Versioning in YANG Notifications Subscription |
| |
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. |
| | Maintaining CCNx or NDN flow balance with highly variable data object sizes |
| |
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| | 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. |
| | Technical Requirements for Secure Access and Management of IoT Smart Terminals |
| |
|
It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. |
| | Open Service Access Protocol for IoT Smart Devices |
| |
|
With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. |
| | 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. |
| | Security Considerations for Tenant ID and Similar Fields |
| |
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| | Model and Test Methods for LTE-V2X Physical Layer Key Distribution System |
| |
|
There are several key distribution systems based on the physical layer of the LTE Vehicle-to-Everything (V2X) communication system, utilizing the random and high-agreement secret key generation schemes from noisy wideband channels. These systems are used in conjunction with physical layer authentication systems that are also based on physical characteristics. To characterize these systems, this document proposes a reference model and several test methods of main technical parameters of such systems, including average key generation rate as well as the consistency and the randomness of generated key bits. |
| | Classic McEliece |
| |
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. |
| | LTE-D Physical Layer Device Authentication Protocol |
| |
|
This document describes a physical layer device authentication protocol based on the physical layer unclonable fingerpint (PUF) technique for LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle- to-Everything), to help the LTE-D message receiver confirm the identity of the LTE-D message sender. PUF utilizes intrinsic nonlinear characters of the transmission signal to identificate the devices and coresponding wireless signal transmitters, and is suitable for critical vehicular communication scenarios by its immunity against traditional cryptographic attacks. The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism. |
| | Support of Network Observation Timestamping in YANG Notifications |
| |
|
This document extends the YANG Notification header with the YANG objects observation timestamping, both for the "push-update" and "push-change-update" notifications. |
| | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
| |
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, and Classic McEliece. |
| | Allowing Experimental Error Codes in the Path Computation Element Protocol |
| |
|
Experimental RFCs are often considered beneficial approaches to developing new protocol features. To that end, sub-ranges of code point registries are often designated as for experimental use. IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). According to RFC 5440 as updated by RFC 8356, the allocation policies for the registries for PCEP messages, objects, and TLV types are IETF Review with some sub-ranges of these registries being assigned for Experimental Use. However, the registry of PCEP Error-Types and Error-values has only the IETF Review assignment policy meaning that experimentation is somewhat limited. This document updates RFC 5440 by designating a range of PCEP Error- Types for Experimental Use. |
| | The Network Geographic identification in Computing-Aware Traffic Steering |
| |
| | draft-ma-cats-ngid-01.txt |
| | Date: |
14/04/2024 |
| | Authors: |
Yuyin Ma, Tianhao Peng, Guoqing Dong, Qixuan Zhang, Xiaoshuang Lv, Guangjing He, Yiyun Zhang, Yuanming Sun, Qihao Si, Haocheng Lang, Xiuling Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a novel network address encoding scheme, called Network Geoidentifier (NGID), which aims to improve the efficiency and accuracy of network device management by directly embedding geolocation information (latitude and longitude) into IPv6 and IPv4 addresses. This approach provides a native support for the geolocation of network devices and is expected to have a significant impact on the future of network management and service positioning. |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-05.txt |
| | Date: |
14/04/2024 |
| | Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| | Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. |
| |
|
| |
| | RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
| |
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| | Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. |
| | A YANG Data Model for Ethernet TE Topology |
| |
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. |
| | Registering Self-generated IPv6 Addresses using DHCPv6 |
| |
| | draft-ietf-dhc-addr-notification-11.txt |
| | Date: |
12/04/2024 |
| | Authors: |
Warren Kumari, Suresh Krishnan, Rajiv Asati, Lorenzo Colitti, Jen Linkova, Sheng Jiang |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses. |
| | A YANG Data Model for Client-layer Tunnel |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. |
| | Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks |
| |
|
Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds fine-grained network management to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF- based YANG and RESTful API capabilities. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces IP Flow Information Export Information Elements to identify information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | IPv4 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs and a new link model for Internetworking. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. |
| | IPv6 Parcels and Advanced Jumbos (AJs) |
| |
|
IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing only a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of- packets", while AJs offer significant operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Network (DTN) link model. |
| | IPv6 Extended Fragment Header |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header that includes a 64-bit Identification; it further defines a control messaging service for fragment retransmission and reassembly congestion management. |
| | IPv6 Extended Fragment Header for IPv4 |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. |
| | Segment Routing Point-to-Multipoint Policy |
| |
| | draft-ietf-pim-sr-p2mp-policy-08.txt |
| | Date: |
12/04/2024 |
| | Authors: |
Dan Voyer, Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments. A SR Point-to-Multipoint (SR P2MP) Policy defines a P2MP tree and a PCE computes and instantiates the tree. |
| | Intra-domain Source Address Validation (SAVNET) Architecture |
| |
|
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. |
| |
|
| |
| | EVPN Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection in [RFC4271], but only for IPVPN and EVPN families. |
| | A YANG Data Model for L1 Connectivity Service Model (L1CSM) |
| |
| | draft-ietf-ccamp-l1csm-yang-26.txt |
| | Date: |
11/04/2024 |
| | Authors: |
Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). |
| | Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator |
| |
|
This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] |
| | Secondary Certificate Authentication of HTTP Servers |
| |
|
This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. |
| | BGP Classful Transport Planes |
| |
| | draft-ietf-idr-bgp-ct-31.txt |
| | Date: |
11/04/2024 |
| | Authors: |
Kaliraj Vairavakkalai, Natrajan Venkataraman |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 procedures and follows RFC 8277 NLRI encoding is defined to advertise underlay routes with its identified class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. |
| | JMAP for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. |
| | JMAP for Contacts |
| |
|
This document specifies a data model for synchronising contacts data with a server using JMAP. |
| | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
RFC 8954 imposed the size constraints on the optional Nonce extension for the Online Certificate Status Protocol (OCSP). OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. Some environments use cryptographic algorithms that generate a Nonce value that is longer than 32 octets. This document updates the maximum allowed length of Nonce to 128 octets. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960. |
| | Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries |
| |
|
This memo describes an architecture for trust registry membership association and verification using Decentralized Identifiers (DIDs), trust registries, and the DNS. This architecture provides a verifier with a simple process by which to determine and verify an issuer's membership in a trust registry. |
| | TCP-AO Protection for BGP Monitoring Protocol (BMP) |
| |
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in RFC5925, for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. 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/hmntsharma/draft-hmntsharma-bmp-tcp-ao. |
| | Updates to RFC Publication Formats |
| |
|
draft-rswg-rfc7990-updates, the successor to RFC 7990, defines the definitive version of an RFC as a published RFC with is in RFCXML. It defines publication versions of the RFC as published RFCs in the publication formats such as PDF, plain text, and HTML. draft-rswg- xml2rfcv3-implemented is updating the specification for the RFCXML format. This document updates some of the publication formats, specifically updating RFC 7992, RFC 7994, RFC 7995, and RFC 8153. Because RFC 7990 mentions some of the features of the publication formats, this document also updates RFC 7990. There is a repository for this draft at https://github.com/paulehoffman/pub-format-updates (https://github.com/paulehoffman/pub-format-updates). |
| | Application-Request Network Framework |
| |
|
With progress of more and more new technologies have been deployed in large scale, such as SRv6 and network slicing, it is highly desirable to open these new capability to applications. Current practice is using ACLs to classify the packet and then map those traffic onto proper network resources. This is the way the application is passively perceived by the network, rather than the application actively calling the network, and changes in application characteristics require triggering network configuration adjustments, making it difficult to deploy at scale. The document proposes a new framework called Application Request Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | RDAP Extension for DNS DELEG |
| |
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. |
| | Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) |
| |
|
This document describes a Same-origin policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients. The same- origin policy concept is a security mechanism to restrict how a document loaded from one origin can cause interaction with resources from another origin. Application of a same-origin policy in RRDP client/server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. This document updates RFC 8182. |
| | A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits |
| |
|
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network ((i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM))) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to ACs that are created using the Attachment Circuit (AC) service ("ietf-ac- svc") and network ("ietf-ac-ntw") models. |
| | Updated RFC Format Framework |
| |
|
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document is the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes how RFCs are published. This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/ (https://datatracker.ietf.org/edwg/rswg/documents/). There is a repository for this draft at https://github.com/paulehoffman/draft- rswg-rfc7990-updates (https://github.com/paulehoffman/draft-rswg- rfc7990-updates). |
| | Static Context Header Compression (SCHC) Architecture |
| |
|
This document defines the SCHC architecture. |
| |
|
| |
| | The IPv6 Compact Routing Header (CRH) |
| |
|
This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, can be addressed with access control lists. Finally, this document encourages replication of the experiment. |
| | Guidelines for Writing Cryptography Specifications |
| |
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. |
| | Sieve Email Filtering: Extension for Processing Calendar Attachments |
| |
| | draft-ietf-extra-processimip-06.txt |
| | Date: |
10/04/2024 |
| | Authors: |
Kenneth Murchison, Ricardo Signes, Matthew Horsfall |
| | Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
This document describes the "processcalendar" extension to the Sieve email filtering language. The "processcalendar" extension gives Sieve the ability to process machine-readable calendar data that is encapsulated in an email message using Multipurpose Internet Mail Extensions (MIME). |
| | Updates to Lightweight OCSP Profile for High Volume Environments |
| |
| | draft-ietf-lamps-rfc5019bis-08.txt |
| | Date: |
10/04/2024 |
| | Authors: |
Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1. |
| | IS-IS Fast Flooding |
| |
| | draft-ietf-lsr-isis-fast-flooding-09.txt |
| | Date: |
10/04/2024 |
| | Authors: |
Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Gunter Van de Velde, Tony Przygienda |
| | Working Group: |
Link State Routing (lsr) |
|
Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. |
| | 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. |
| | RESTCONF Extension to support Trace Context Headers |
| |
|
This document extends the RESTCONF protocol in order to support trace context propagation as defined by the W3C. |
| | INIT Forwarding for the Stream Control Transmission Protocol |
| |
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. |
| | dCBOR: A Deterministic CBOR Application Profile |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The CBOR Common Deterministic Encoding (CDE) Internet Draft builds on this by specifying a baseline for application profiles that wish to implement deterministic encoding with CBOR. The present document provides an application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding based on CDE for a variety of applications wishing an even narrower and clearly defined set of choices. |
| | Crowd Sourced Remote ID |
| |
|
This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. |
| | Methods for Remotely Measuring IP Spoofing Capability |
| |
|
This document summarizes and standardizes methods for remotely measuring a network's IP spoofing capability. For outbound spoofing capability measurement, i.e., whether the network allows IP spoofing traffic to be sent from inside the network to the outside of the network, DNS traceroute can be used to check whether spoofed packets are generated in the network and sent to outside of the network. For inbound spoofing capability measurment, i.e., whether the network allows IP spoofing traffic from the outside the network to arrive inside, DNS resolver and ICMPv6 rate limiting mechanism can be utilized to check whether spoofed packets are received by devices in the network. |
| | Privacy Pass Issuance Protocols with Public Metadata |
| |
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
| | Multipath Extension for QUIC |
| |
| | draft-ietf-quic-multipath-07.txt |
| | Date: |
10/04/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/mirjak/draft-lmbdhk-quic-multipath. |
| |
|
| |
| | Preference for IPv6 ULAs over IPv4 addresses in RFC6724 |
| |
|
When RFC 6724 was published it defined an address selection algorithm along with a default policy table, and noted a number of examples where that policy table might benefit from adjustment for specific scenarios. It also noted that it is important for implementations to provide a way to change the default policies as more experience is gained. This update draws on several years of operational experience to refine RFC 6724 further, with particular emphasis on preference for the use of ULA addresses over IPv4 addresses and the addition of mandatory support for Rule 5.5. The update also demotes the preference for 6to4 addresses. The changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. |
| | BFD Encapsulated in Large Packets |
| |
|
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. |
| | Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) |
| |
| | draft-ietf-core-oscore-edhoc-11.txt |
| | Date: |
09/04/2024 |
| | Authors: |
Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander |
| | Working Group: |
Constrained RESTful Environments (core) |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. |
| | Encapsulation For MPLS Performance Measurement with Alternate Marking Method |
| |
|
This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | PCEP Procedures and Extension for VLAN-based Traffic Forwarding |
| |
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. |
| | Trusted Domain SRv6 |
| |
|
SRv6 as designed has evoked interest from various parties, though its deployment is being limited, amongst other things, by known security problems in its architecture. This document specifies a standard way to create a solution that closes some of the major security concerns, while retaining the tenants of the SRv6 protocol. |
| | High Assurance DIDs with DNS |
| |
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| | Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses |
| |
| | draft-sipcore-rfc7976bis-01.txt |
| | Date: |
09/04/2024 |
| | Authors: |
Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske |
| | Working Group: |
Individual Submissions (none) |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
| | Proof of Issuer Key Authority (PIKA) |
| |
|
A relying party verifying a JSON Web Token (JWT) needs to verify that the public key used to verify the signature legitimately represents the issuer represented in the "iss" claim of the JWT. Today, relying parties commonly use the "iss" claim to fetch a set of authorized signing keys over HTTPS, relying on the security of HTTPS to establish the authority of the downloaded keys for that issuer. The ephemerality of this proof of authority makes it unsuitable for use cases where a JWT might need to be verified for some time. In this document, we define a format for Proofs of Issuer Key Authority, which establish the authority of a key using a signed object instead of an HTTPS connection. |
| | SRv6 Resource Programming with NRP flavor |
| |
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| | RPKI Signed Object for Trust Anchor Key |
| |
| | draft-ietf-sidrops-signed-tal-15.txt |
| | Date: |
09/04/2024 |
| | Authors: |
Carlos Martinez, George Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein |
| | Working Group: |
SIDR Operations (sidrops) |
|
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support planned key rolls without impacting RPKI validation. |
| | Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes |
| |
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with attributes signaling validation state may flood needless BGP UPDATE messages through the global Internet routing system, when, for example, Route Origin Authorizations are issued, revoked, or RPKI-To- Router sessions are terminated. Operators SHOULD ensure Validation States are not signalled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into distinct BGP Communities. |
| |
|
| |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | Internet Message Format |
| |
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
| | Protocol Numbers for SCHC |
| |
|
This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. |
| | A Decent LISP Mapping System (LISP-Decent) |
| |
|
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. |
| | Crowd Sourced Remote ID |
| |
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| | Revised Cookie Processing in the IKEv2 Protocol |
| |
|
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. |
| | The Time Zone Information Format (TZif) |
| |
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. |
| | A Blockchain Trusted Protocol for Intelligent Communication Network |
| |
|
This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. |
| | Bundle Protocol Endpoint ID Patterns |
| |
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and CBOR encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its CBOR form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [RFC6831] and [RFC8378] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to- 1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | Computing-aware Traffic Steering for attack detection |
| |
|
This document describes the closed-loop framework for computing-aware traffic steering for attack detection (CATS-AD). The computing-aware traffic steering is determined by composing selected service instances and overlay links. The service instances are selected according to the computing power of service instances. This document describes the closed-loop framework for attacks detection and how to select and combine service instances to form a computing-aware service function chain (SFC). |
| | EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay |
| |
| | draft-xie-v6ops-evn6-01.txt |
| | Date: |
08/04/2024 |
| | Authors: |
Chongfeng Xie, Xing Li, Congxiao Bao, Mark Smith, Jibin Sun |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| | PCEP Extensions for Signaling Multipath Information |
| |
| | draft-ietf-pce-multipath-11.txt |
| | Date: |
08/04/2024 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra |
| | Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new PCEP mechanisms are meant to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to isse more than one token at a time. |
| |
|
| |
| | BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover |
| |
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. |
| | Integrity of In-situ OAM Data Fields |
| |
|
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features to ensure their security. This document describes the integrity protection of IOAM-Data-Fields. |
| | ICANN Registry Interfaces |
| |
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| | ICANN Registrar Interfaces |
| |
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| | The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. |
| | Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
| |
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| | Terminal-based joint selection and configuration of MEC host and RAW network |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | Extensions to enable wireless reliability and availability in multi-access edge deployments |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | MIPv6 RAW mobility |
| |
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| | RAW multidomain extensions |
| |
|
This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. |
| | Discovery of Network Rate-Limit Policies (NRLPs) |
| |
|
Traffic exchanged over a network attachment may be subject to rate- limit policies. These policies may be intentional policies (e.g., enforced as part of the activation of the network attachment and typically agreed upon service subscription) or be reactive policies (e.g., enforced temporarily to manage an overload or during a DDoS attack mitigation). Networks already support mechanisms to advertize a set of network properties to hosts using Neighbor Discovery options. Examples of such properties are link MTU (RFC 4861) and PREFIX64 (RFC 8781). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate these policies to hosts. For address family parity, a new DHCP option is also defined. |
| |
|
| |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. |
| | 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. |
| | Dynamic Flooding on Dense Graphs |
| |
|
Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. |
| | MPLS Network Actions (MNA) Framework |
| |
| | draft-ietf-mpls-mna-fwk-07.txt |
| | Date: |
05/04/2024 |
| | Authors: |
Loa Andersson, Stewart Bryant, Matthew Bocci, Tony Li |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. The document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. Some of these actions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements found in "Requirements for MPLS Network Actions". |
| | Optimizations of PCEP Link-State(LS) Synchronization Procedures |
| |
|
For a Path Computation Element (PCE) to perform its computations, it is important that Link-State (and TE) information be complete and accurate each time. This requires a reliable Link-State Synchronization mechanism between the PCE and path computation clients (PCCs), and between cooperating PCEs. The basic mechanism for Link-State Synchronization is part of the PCEP Link-State (and TE) draft. This draft presents motivations for optimizations to the base PCEP Link-State (and TE) procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. |
| | ICMP Extensions for Environmental Information |
| |
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental impact information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental- impact metrics. |
| | MIMI Metadata Minimalization (MIMIMI) |
| |
|
This document describes a proposal to run the MIMI protocol in a way that reduces the ability of the Hub and service providers to associate messaging activity of clients with their respective identities. For now, this document only contains a high-level description of the mechanisms involved. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-04.txt |
| | Date: |
05/04/2024 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| | Detecting RRDP Session Desynchronization |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. |
| | Hybrid key exchange in TLS 1.3 |
| |
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. |
| | Best Current Practice for Workload Identity |
| |
|
The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and client_secret, can be complex and error-prone. "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads. This document specifies the use of JWTs for client credentials in container orchestration systems to improve interoperability in orchestration systems, to reduce complexity for developers, and motivates authorization server to support RFC 7523. |
| |
|
| |
| | WebP Image Format |
| |
| | draft-zern-webp-15.txt |
| | Date: |
04/04/2024 |
| | Authors: |
James Zern, Pascal Massimino, Jyrki Alakuijala |
| | Working Group: |
Applications and Real-Time Area (art) |
|
This document defines the WebP image format and registers a media type supporting its use. |
| | IMAP Extension for only using and returning UIDs |
| |
| | draft-ietf-extra-imap-uidonly-08.txt |
| | Date: |
04/04/2024 |
| | Authors: |
Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Ashutosh Singh, Luis Alves |
| | Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
The UIDONLY extension to the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses, and can't be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs. This document defines an experimental IMAP extension. |
| | IMAP4 Response Code for Command Progress Notifications. |
| |
|
This document defines a new IMAP untagged response code, "INPROGRESS", that provides structured numeric progress status indication for long-running commands. |
| | JMAP for Sieve Scripts |
| |
|
This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. |
| | Clarification of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-09.txt |
| | Date: |
04/04/2024 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. |
| | No Revocation Available for X.509 Public Key Certificates |
| |
| | draft-ietf-lamps-norevavail-04.txt |
| | Date: |
04/04/2024 |
| | Authors: |
Russ Housley, Tomofumi Okubo, Joseph Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
X.509v3 public key certificates are profiled in RFC 5280. Short- lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm in RFC 5280 to skip revocation checking when the noRevAvail certificate extension is present. |
| | YANG Groupings for TCP Clients and TCP Servers |
| |
|
This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| | Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
| |
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| | Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
| |
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| | Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
| |
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| | Multiple IPv4 - IPv6 address mapping translator (M46T) |
| |
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| | Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E) |
| |
|
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. |
| | Multi-Stage Transparent Server Load Balancing |
| |
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| | Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
| |
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| | ESP Echo Protocol |
| |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | Gender Representation in the IETF Nominating Committees |
| |
|
This document extends the existing limit on nomcom representation by company in order to improve gender diversity by ensuring that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. |
| | Registry policies "... with Expert Review" |
| |
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing |
| |
|
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element(PCE). Since SR can be applied to both MPLS and IPv6 data-planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data- planes. The Path Computation Element communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data-plane within PCEP. |
| | Secure Frame (SFrame) |
| |
| | draft-ietf-sframe-enc-09.txt |
| | Date: |
04/04/2024 |
| | Authors: |
Emad Omara, Justin Uberti, Sergio Murillo, Richard Barnes, Youenn Fablet |
| | Working Group: |
Secure Media Frames (sframe) |
|
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (selective forwarding units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
| |
| | draft-ietf-spring-stamp-srpm-14.txt |
| | Date: |
04/04/2024 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The procedure described is used for links, SR paths (including SR Policies and SR Flexible Algorithm IGP paths) as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. |
| |
|
| |
| | COSE "typ" (type) Header Parameter |
| |
|
This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) typ (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing, as defined in the JSON Web Token Best Current Practices BCP, to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. |
| | IMAP4 Extension for Returning Mailbox METADATA in Extended LIST |
| |
|
This document defines an extension to the to IMAP LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. |
| | Federated TLS Authentication |
| |
|
This document describes the Federated TLS Authentication (FedTLS) protocol, enabling secure end-to-end communication within a federated environment. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedTLS ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. |
| | Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages |
| |
|
This document describes a PTP Profile for the use of the Precision Time Protocol in an IPv4 or IPv6 Enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allows both multicast and unicast Delay Request and Delay Response messages. |
| | TLS 1.2 is in Feature Freeze |
| |
|
TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, no new features will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |
| | Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks |
| |
|
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD, RFC8415). |
| |
|
| |
| | A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services |
| |
|
This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types of network resources. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-00.txt |
| | Date: |
02/04/2024 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| | An Architecture for More Instant Messaging Interoperability (MIMI) |
| |
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-00.txt |
| | Date: |
02/04/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. |
| | OSPF Abnormal State Information |
| |
|
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. |
| | Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path |
| |
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. |
| | Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path |
| |
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. |
| | A Forward-Search P2P TE LSP Inter-Domain Path Computation |
| |
|
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| | A Forward-Search P2MP TE LSP Inter-Domain Path Computation |
| |
|
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| | The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks. |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. |
| | Extensions to PCEP for Distributing Label Cross Domains |
| |
|
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). |
| | BGP Extensions for IDs Allocation |
| |
|
This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed. |
| | BGP-SPF Flooding Reduction |
| |
|
This document describes extensions to Border Gateway Protocol (BGP) for flooding the link states on a topology that is a subgraph of the complete topology of a BGP-SPF domain, so that the amount of flooding traffic in the domain is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. |
| | IGP Extensions for Advertising Node Index |
| |
| | draft-chen-lsr-adv-ni-04.txt |
| | Date: |
02/04/2024 |
| | Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| | Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. |
| | SR-MPLS FRR Extension |
| |
|
The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node on an SR-MPLS path by the neighbor upstream node as point of local repair (PLR) of the failed node. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbor upstream node of the failed node will no longer have a route to the failed node. This document describes a simple mechanism to extend the fast re-route protection for the failure on an SR-MPLS path after the IGP converges. The mechanism protects the node SID, adjacency SID and binding SID of the failed node on the path. |
| | External Keys For Use In Internet X.509 Certificates |
| |
|
Many of the post quantum cryptographic algorithms have large public keys. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and algorithms for referencing external public key data by hash, and location, for example URL. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. |
| | 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. |
| | Closing the RTP Payload Format Media Types IANA Registry |
| |
|
It has been observed that specifications of new RTP payload formats often forget to register themselves in the IANA regsitry "RTP Payload Formats Media Types". In practice this has no real impact. One reason is that the Media Types registry is the crucial regsistry to register any Media Type to establish the media type used to identified the format in various signalling usage. To resolve this sitaution this document performs the following. First it updates the registry to include known RTP payload formats at the time of writing. Then it closes the IANA Registry for RTP Payload formats Media Types for future registration. Beyond instructing IANA to close this registry the instructions to authors in RFC 8088 are updated that registration is no longer required in the closed registry. |
| | Proposal for the Introduction of Email Headers for Phishing Detection Training |
| |
|
This document proposes the addition of new email headers designed specifically to identify emails that are sent as part of phishing detection training programs. These headers would allow recipients to verify the authenticity of training emails using DNS queries to confirm that the sending domains are authorized to send these types of emails. |
| | DataRight+: Admission Control Baseline |
| |
|
The establishment of a shared model of trust is critical to any functioning technology ecosystem, particularly when it relates to the sharing of data and the execution of Consumer specific actions. Traditional models of trust have typically revolved around implicit trust established through bi-lateral arrangements (i.e. legal contracts) between participants. The issue with this approach is that, at scale, it is not possible for all participants to efficiently establish communication with all other participants. This leads to the requirement for a mechanism to establish trust across participants in a way that the business layer of an organisation has confidence in ensuring participant interaction is validated. |
| | DataRight+: Australian CDR Profile |
| |
|
This is the ecosystem profile for the Australian CDR describing the composite components to form the technical infrastructure operating to form the Australian Consumer Data Right. This specification is intended to result in a [CDS] compatible implementation. Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| | YANG Model for the NETCONF default attribute |
| |
|
This document defines a YANG module with the "default" attribute using the namespace and prefix defined in [RFC6243]. This enables usage of the "default" attribute in e.g. YANG JSON encoding. |
| | EAT Media Types |
| |
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). |
| | The SSLKEYLOGFILE Format for TLS |
| |
|
A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. |
| |
|
| |
| | Usage Limits on AEAD Algorithms |
| |
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| | Key Blinding for Signature Schemes |
| |
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| | Properties of AEAD Algorithms |
| |
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. |
| | DRIP Entity Tag (DET) Identity Management Architecture |
| |
|
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts is performed via DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. |
| | The Link-Template HTTP Header Field |
| |
|
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. |
| | Multicast On-path Telemetry using IOAM |
| |
|
This document specifies the requirements of on-path telemetry for multicast traffic using In-situ OAM. While In-situ OAM is advantageous for multicast traffic telemetry, some unique challenges are present. This document provides the solutions based on the In- situ OAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. |
| | The FNV Non-Cryptographic Hash Algorithm |
| |
| | draft-eastlake-fnv-22.txt |
| | Date: |
01/04/2024 |
| | Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| | Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that is referenced in a number of standards documents and widely used. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. |
| | IPv6 is Classless |
| |
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| | Information Awareness System for Computing-Aware Service Function Chain (IAS-CASFC): Security Service Aspect |
| |
|
This document describes the Information Awareness System of the Computing-Aware Service Function Chain (ISA-CASFC) from the security service aspect, including the system architecture, network, and computing information details. The SFC enables traffic to pass through the ordered Network Security Function (NSF) path, enabling end-to-end security services. Differences in the available network and computing resources cause performance differences between NSF instances deployed on different service sites. It can be seen that the routing decision on NSF instances will affect the quality of the security service. Therefore, it is necessary to implement the CA-SFC to ensure the quality of security service. This document extends the CATS framework and the CATS Computing and Network Information Awareness (CNIA) architecture for CA-SFC, and describes the network and computing information content for security service. |
| | DataRight+: Energy Resource Set |
| |
|
This is the resource set profile outlining the energy sector related endpoints. In addition to outlining Initiator and Provider provisions it also specifies requirements for the Energy Authority (electricity assets and usage) and Energy Plan Website (retail electricity plan information). Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| | DataRight+: Common Resource Set |
| |
|
This is the resource set profile outlining the common endpoints utilised across multiple industries. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| | DataRight+: Banking Resource Set |
| |
|
This is the resource set profile outlining the banking sector related endpoints. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| | DataRight+ Security Profile: Baseline |
| |
|
The DataRight+ Security Profile: Baseline is intended to be a compatible profile of the [CDS] presented as a profile of [FAPI-1.0-Advanced]. This profile focuses primarily on the obligations between Provider and Initiator with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of specified authorisation types. This profile does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the [CDS]. Further terminology used is deliberately jurisdiction agnostic, please refer to [DATARIGHTPLUS-ROSETTA] for specific ecosystem mappings. |
| | DataRight+: Sharing Arrangement V1 |
| |
|
This specification outlines the technical requirements related to the delivery of Sharing Arrangement V1. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| | IGMP and MLD Snooping Yang Module Extension for L2VPN |
| |
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. |
| | Rate-Limited Token Issuance Protocol |
| |
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. |
| | The PrivateToken HTTP Authentication Scheme Extensions Parameter |
| |
|
This document specifies a new parameter for the "PrivateToken" HTTP authentication scheme. This purpose of this parameter is to carry extensions for Privacy Pass protocols that support public metadata. |
| | RIFT: Routing in Fat Trees |
| |
| | draft-ietf-rift-rift-21.txt |
| | Date: |
01/04/2024 |
| | Authors: |
Tony Przygienda, Jordan Head, Alankar Sharma, Pascal Thubert, Bruno Rijsman, Dmitry Afanasiev |
| | Working Group: |
Routing In Fat Trees (rift) |
|
This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects, and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP fabrics as well. The protocol specified by this document is optimized toward the minimization of control plane state to support very large substrates as well as the minimization of configuration and operational complexity to allow for simplified deployment of said topologies. |
| | Return Routability Check for DTLS 1.2 and DTLS 1.3 |
| |
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. |