|
|
| |
| BFD Stability |
|
| draft-ietf-bfd-stability-12.txt |
| Date: |
31/01/2024 |
| Authors: |
Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Santosh Pallagatti, Mach Chen, Peng Fan |
| Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD packet loss. |
| Structured Error Data for Filtered DNS |
|
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| Common Format and MIME Type for Comma-Separated Values (CSV) Files |
|
|
This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". |
| Ethernet VPN Virtual Private Wire Services Gateway Solution |
|
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. |
| Destination/Source Routing |
|
|
This note specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. This applies to IPv6 [RFC2460] in general with specific considerations for routing protocol left for separate documents. There is nothing precluding similar operation in IPv4, but this is not in scope of this document. Note that destination/source routing, source/destination routing, SADR, source-specific routing, source-sensitive routing, S/D routing and D/S routing are all used synonymously. |
| Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs) |
|
|
The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number of key shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical split- key PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. |
| Mail Autoconfig |
|
|
Set up a mail account with only email address and password. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://benbucksch.github.io/autoconfig-spec/draft-autoconfig-1.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-autoconfig-1/. Source for this draft and an issue tracker can be found at https://github.com/benbucksch/autoconfig-spec. |
| Update to the use of Internet-Drafts in the Internet Standards Process |
|
|
This memo updates the way that Internet-Drafts are used in the Internet Standards Process. Rather than expiring, Internet-Drafts are marked Active or Inactive. Also, the rules for referencing Internet-Drafts in other documents are clarified. |
| YANG Models for Quality of Service (QoS) |
|
| draft-ietf-rtgwg-qos-model-12.txt |
| Date: |
31/01/2024 |
| Authors: |
Aseem Choudhary, Mahesh Jethanandani, Ebben Aries, Helen Chen |
| Working Group: |
Routing Area Working Group (rtgwg) |
|
This document describes a YANG model for configuration and operational data of Quality of Service (QoS) in network devices. |
|
|
| |
| Common Interface Extension YANG Data Models |
|
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| Sub-interface VLAN YANG Data Models |
|
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orignating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. |
| Extensions to the Access Control Lists (ACLs) YANG Model |
|
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. |
| IS-IS Flooding Reduction in MSDC |
|
|
IS-IS is a commonly used routing protocol in MSDC (Massively Scalable Data Center) networks where CLOS is the most popular topology. In a CLOS topology, each IS-IS router would receive multiple copies of the same LSP (Link State Packet) from multiple IS-IS neighbors. Moreover, two IS-IS neighbors may send each other the same LSP simultaneously. The unnecessary link-state information flooding results in a large waste of resources for IS-IS routers, as there are too many neighbors for each router. To address this scaling problem, this document introduces some extensions to the IS-IS protocol. These extensions aim to significantly reduce the IS-IS flooding within MSDC networks, which can greatly improve the scalability of such networks. |
| ACME-Based Provisioning of IoT Devices |
|
|
This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. |
| Email identity |
|
|
To have a way in PHP and html to get the email identities and phone numbers that logged into the client IP address that viewed a wevsite |
| Link-Layer Types for PCAP and PCAPNG Capture File Formats |
|
|
This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. |
| Checking Resource Consistency with HTTP Mirrors |
|
|
This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. |
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
|
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations |
|
|
| |
| A YANG Data Model for Flexi-Grid Optical Networks |
|
| draft-ietf-ccamp-flexigrid-yang-16.txt |
| Date: |
29/01/2024 |
| Authors: |
Universidad de Madrid, Daniel Burrero, Daniel King, Young Lee, Haomian Zheng |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. |
| A YANG Data Model for Transport Network Client Signals |
|
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. |
| rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP |
|
| draft-irtf-iccrg-rledbat-06.txt |
| Date: |
29/01/2024 |
| Authors: |
Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen Balasubramanian |
| Working Group: |
Internet Congestion Control (iccrg) |
|
This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. |
| Stateless and Scalable Network Slice Identification for SRv6 |
|
|
This document defines a stateless and scalable solution to achieve network slicing with SRv6. |
| IPv6 Site connection to many Carriers |
|
|
Carrier resilience is a typical business requirement. IPv4 deployments have traditionally solved this challenge through private internal site addressing in combination with separate NAT engines attached to multiple redundant carriers. IPv6 brings support for true end-to-end connectivity on the Internet, and hence NAT is the least desirable option in such deployments. Native IPv6 solutions for carrier resiliency, however, have drawbacks. This document discusses all currently-available options to organize carrier resiliency for a site, their strengths and weaknesses, and provides a history of past IETF efforts approaching the issue. The views presented here are the summary of discussions on the v6ops mailing list and are not just the personal opinion of the authors. |
| Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism |
|
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). |
|
|
| |
| Deadline-aware Transport Protocol |
|
| draft-shi-quic-dtp-09.txt |
| Date: |
28/01/2024 |
| Authors: |
Yong Cui, Chuan Ma, Hang Shi, Kai Zheng, Wei Wang |
| Working Group: |
Individual Submissions (none) |
|
This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery. |
| Identity Module for TLS Version 1.3 |
|
|
TLS 1.3 will be deployed in the Internet of Things ecosystem. In many IoT frameworks, TLS or DTLS protocols, based on pre-shared key (PSK), are used for device authentication. So PSK tamper resistance, is a critical market request, in order to prevent hijacking issues. If DH exchange is used with certificate bound to DH ephemeral public key, there is also a benefit to protect its signature procedure. The TLS identity module (im) MAY be based on secure element; it realizes some HKDF operations bound to PSK, and cryptographic signature if certificates are used. Secure Element form factor could be standalone chip, or embedded in SoC like eSIM. |
| MTU propagation over EVPN Overlays |
|
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. |
| Defreezing Optimization post EVPN Mac Dampening |
|
|
MAC move handling in EVPN deployments is discussed in detail in [RFC7432]. There are few optimizations which can be done in existing way of handling the mac duplication. This document describes few of the potential techniques to do so. This document is of informational type based on comments in the ietf meeting. |
| All PEs as DF |
|
|
The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. |
| Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth |
|
|
Flow-ID Label (FL) is used for MPLS flow identification and flow- based performance measurement with alternate marking method. The ability to process Flow-ID labels is called Flow-ID Label Capability (FLC), and the capability of reading the maximum label stack depth and performing FL-based performance measurement is called Flow-ID Readable Label Depth (FRLD). This document defines a mechanism to signal the FLC and the FRLD using IGP and BGP-LS. |
| Use Cases-Standalone Service ID in Routing Network |
|
| draft-huang-rtgwg-us-standalone-sid-00.txt |
| Date: |
28/01/2024 |
| Authors: |
Daniel Huang, gechen, Jie Liang, Yan Zhang, Feng Yang, Dong Yang, Dongyu Yuan, FUHUAKAI, Cheng Huang, Yong Guo |
| Working Group: |
Individual Submissions (none) |
|
More and more emerging applications have raised the demand for establishing networking connections anywhere and anytime, alongside the availability of highly distributive any-cloud services. Such a demand motivates the need to efficiently interconnect heterogeneous entities, e.g., different domains of network and cloud owned by different providers, with the goal of reducing cost, e.g., overheads and end-to-end latency, while ensuring the overall performance satisfies the requirements of the applications. Considering that different network domains and cloud providers may adopt different types of technologies, the key of interconnection and efficient coordination is to employ a unified interface that can be understood by heterogeneous parties which could derive the consistent requirements of the same service and treat the service traffic appropriately by their proprietary policies and technologies. This document provides use cases and problem statements from two main Internet traffic categories: one is the traditional north-south traffic which is defined from clients to entities (such as servers or DCs), and the other is east-west traffic which refers to traffic between entities (such as inter-server or inter-service).The requirements for a standalone Service ID are also derived. |
| Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2) |
|
|
This document defines a set of cryptographic transforms for using in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms are mandatory in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. |
| Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
|
| draft-ietf-pce-pcep-pmtu-05.txt |
| Date: |
28/01/2024 |
| Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor |
| Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available at the headend. This document specify the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR and other scenarios. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
|
|
| |
| BIER Ping and Trace |
|
| draft-ietf-bier-ping-13.txt |
| Date: |
27/01/2024 |
| Authors: |
Nagendra Nainar, Carlos Pignataro, Mach Chen, Greg Mirsky |
| Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast-related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. |
| Matroska Media Container Codec Specifications |
|
| draft-ietf-cellar-codec-12.txt |
| Date: |
27/01/2024 |
| Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block Element and in an optional CodecPrivate Element. |
| Matroska Media Container Control Track Specifications |
|
| draft-ietf-cellar-control-04.txt |
| Date: |
27/01/2024 |
| Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Control Track usage found in the Matroska container. |
| Matroska Media Container Chapter Codecs Specifications |
|
|
This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. |
| Signaling Maximum Transmission Unit (MTU) using BGP-LS |
|
|
BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path mtu of SR tunnel. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. |
| Tracing process in IPv6 VPN Tunneling Networks |
|
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. |
| Mappings Between XML2RFC v3 and AsciiDoc |
|
|
This document specifies a mapping between XML2RFC v3 and AsciiDoc. The goal of this mapping and its associated tooling is to make writing an Internet-Draft as simple as possible, by converting any AsciiDoc formatted document into a valid Internet-Draft, ready to be submitted to the IETF. This is still work in progress and for the time being this mapping only ensures that any valid XML2RFC element can be generated from AsciiDoc. |
| IGP Extensions for Link MTU |
|
|
Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths which are called segments. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS and OSPF extensions about the Path MTU that need to be used on SR. Here, the term "OSPF" means both OSPFv2 and OSPFv3. |
|
|
| |
| Updated BGP Operations and Security |
|
|
The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security and reliability measures that can and should be deployed to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publications of RFC7454 / BCP194, several developments and changes in operational practice took place that warrant an update of these best current practices. This document replaces RFC7454 / BCP194, reiterating the best practices for BGP security from that document and adding new practices and recommendations that emerged since its publication. This document provides a comprehensive list of Internet specific BGP security and reliability related best practices as of the time of publication. It specifically does not cover other uses of BGP, e.g., in a datacenter context. While the recommendations in this document are, in general, best practices, operators still need to carefully weigh individual measures vs. their local network requirements before implementing them. Also, as with BCP194, best practices outlined in this document may have changed since its publication. |
| IPSec for BGP Enabled Services over SRv6 |
|
|
This document describes an approach to encrypting selective user data flows using IPsec and then orchestrating the encrypted flows based on the SRv6 Policy path. The method is needed for some users or applications that demand an elevated level of security, necessitating the encryption of their data flows even within networks like SRv6, which are built and managed by Network Service Providers (NSP) and generally considered secure. Employing encryption for selective flows over NSP managed networks, including technologies like SRv6, adds an extra layer of protection, safeguarding valuable data from potential breaches and enhancing overall network security. |
| RFC 6296bis IPv6-to-IPv6 Network Prefix Translation |
|
|
This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network 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/buraglio/rfc6296-bis. |
| Extensible Provisioning Protocol (EPP) mapping for DELEG records |
|
|
This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names. 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-deleg-extension. |
|
|
| |
| Prefix Flag Extension for OSPFv2 and OSPFv3 |
|
|
Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix Attribute Flags Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. |
| Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space |
|
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a generic mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other to-be-defined identifier that can be allocated and managed by the PCE. |
| NTPv5 Use Cases and Requirements |
|
|
This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supersede version 4 of the NTP protocol presently referred to as NTP version 5 ("NTPv5"). It aims to define what capabilities and requirements such a protocol possesses, informing the design of the protocol in addition to capturing any working group consensus made in development. |
| Guidance on RESTful Design for Internet of Things Systems |
|
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). |
|
|
| |
| H.265 Profile for WebRTC |
|
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, similar guidance is needed for browsers considering support for the H.265 codec, whose RTP payload format is defined in RFC 7798. |
| Framework and Data Model for OTN Network Slicing |
|
| draft-ietf-ccamp-yang-otn-slicing-06.txt |
| Date: |
24/01/2024 |
| Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. |
| A YANG Model for MPLS MSD |
|
| draft-ietf-mpls-msd-yang-05.txt |
| Date: |
24/01/2024 |
| Authors: |
Yingzhen Qu, Acee Lindem, Stephane Litkowski, Jeff Tantsura |
| Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines a YANG data model augmenting the IETF MPLS YANG model to provide support for MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491. |
| BGP-LS Extensions for SR Network Resource Partition SIDs |
|
|
This document specifies extensions to the BGP Link-state address- family in order to advertise the information of Network Resource Partition SIDs. An external component (e.g., a controller) then can collect Network Resource Partition SIDs in the "northbound" direction. The draft is applicable to both SR-MPLS and SRv6 dataplanes. |
| AS Hijack Detection and Mitigation |
|
|
This document proposes a method for detection and mitigation of AS hijacking. In this mechanism, an AS operator registers a new object in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is digitally signed using the AS holder's certificate. By registering a REAP object, the AS operator is declaring that they have Route Origin Authorization (ROA) coverage for all prefixes originated by their AS. A receiving AS will mark a route as Invalid if the prefix is not covered by any Validated ROA Payload (VRP) and the route origin AS has signed a REAP. Here Invalid means that the route is determined to be an AS hijack. |
| Encrypted Client Hello Deployment Considerations |
|
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. |
| Encryption algorithm Rocca-S |
|
| draft-nakano-rocca-s-05.txt |
| Date: |
24/01/2024 |
| Authors: |
Yuto Nakano, Kazuhide Fukushima, Takanori Isobe |
| Working Group: |
Individual Submissions (none) |
|
This document defines Rocca-S encryption scheme, which is an Authenticated Encryption with Associated Data (AEAD), using a 256-bit key and can be efficiently implemented utilizing the AES New Instruction set (AES-NI). |
| The Requirements of a Unified Transport Protocol for In-Network Computing in Support of RPC-based Applications |
|
|
In-network computing breaks the end-to-end principle and introduces new challenges to the transport layer functionalities. This draft provides the background of a suite of RPC-based applications which can take advantage of INC support, surveys the existing transport protocols to show they are insufficient or improper to be used in this context, and lays out the requirements to develop a general transport protocol tailored for such applications. The purpose of this draft is to help understand the problem domain and inspire the design and development a unified INC transport protocol. |
| Sustainability Considerations for Internetworking |
|
|
This document defines a set of sustainability-related terms to be used while describing and evaluating environmental impacts of Internet technologies. It also describes several of the design tradeoffs for trying to optimize for sustainability along with the other common networking metrics such as performance and availability. Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementors sustainability- related advice and guideance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs. |
| Secure Asset Transfer (SAT) Use Cases |
|
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. |
|
|
| |
| A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
|
| draft-ietf-bier-te-yang-06.txt |
| Date: |
23/01/2024 |
| Authors: |
Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh Sivakumar, chenhuanan |
| Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document defines a YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. |
| Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application |
|
| draft-ietf-ccamp-dwdm-if-lmp-09.txt |
| Date: |
23/01/2024 |
| Authors: |
Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This memo defines extensions to LMP RFC4209 for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1 and its extensions. |
| The Signature HTTP Authentication Scheme |
|
|
Existing HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document proposes a new non-probeable cryptographic authentication scheme. |
| Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) |
|
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. |
| Multicast Redundant Ingress Router Failover |
|
|
This document discusses multicast redundant ingress router failover issues, include global multicast and Service Provider Network MVPN use case. This document analyzes specification of global multicast and Multicast VPN Fast Upstream Failover and the Ingress PE Standby Modes and the benefits of each mode. |
| Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application |
|
|
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson). |
| BIER in BABEL |
|
|
BIER introduces a novel multicast architecture. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per- flow state. Babel defines a distance-vector routing protocol that operates in a robust and efficient fashion both in wired as well as in wireless mesh networks. This document defines a way to carry necessary BIER signaling information in Babel. |
| Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems. |
|
|
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1 and its extensions and G.872. |
| Retrieving information about Object Identifiers using a text-based protocol |
|
|
This document defines a method for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) through a text-based protocol, in a way that is both human-readable and machine-readable. Besides a text output format, OID-IP also supports sending information in JSON and XML. |
| Problem Statement and Use Cases of Trustworthiness-based Routing |
|
|
Currently, network operators are trying to provide fine-granularity Service Level Agreement (SLA) guarantee to achieve better Quality of Experience (QoE) for end users and engage customers, such as ultra- low latency and high reliability service. However, with increasing security threats, differentiated QoE services are insufficient, the demands for more differentiated security service are emerging. This document explores the requirements for differentiated security services and identifies the scenarios for network operators. To provide differentiated security services, possible trustworthiness- based routing solution is discussed. |
| IGP POI for Intra-domain SAV |
|
|
This document describes an IGP Prefix Originated Indicator (POI) method for Source Address Validation (SAV) on routers to mitigate source address spoofing attack and improve the accuracy of source address validation in intra-domain networks. |
| Extensible Delegation for DNS |
|
| draft-dnsop-deleg-00.txt |
| Date: |
23/01/2024 |
| Authors: |
Tim April, Petr Spacek, Ralf Weber, tale |
| Working Group: |
Individual Submissions (none) |
|
A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. |
| MPLS FRR bypass path calculation with bandwidth awareness without reservation |
|
|
RFC4090 documents facility backup FRR in MPLS-TE networks. This document describes methods that allow the Point of Local Repair (PLR) to find a path with sufficient available bandwidth to accommodate protected traffic, while not making undesired reservations that would require additional capacity. Below aspects are covered: * Automatic determination of bypass required bandwidth by the PLR * Calculation of path based on this information using constrained shortest path algorithm (CSPF) * Determination of RSVP SENDER-TSPEC rate value for bypass tunnel signaling |
| Export of UDP Options Information in IP Flow Information Export (IPFIX) |
|
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. |
| IANA Registry Updates for TLS and DTLS |
|
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. |
|
|
| |
| Multicast Source Redundancy in EVPN Networks |
|
|
Ethernet Virtual Private Network (EVPN) supports intra and inter- subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures. |
| Definition For New BMP Statistics Type |
|
|
RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router. This document updates RFC 7854 by adding new statistics type. |
| A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane |
|
| draft-ietf-isis-sr-yang-21.txt |
| Date: |
22/01/2024 |
| Authors: |
Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Helen Chen, Jeff Tantsura |
| Working Group: |
Link State Routing (lsr) |
|
This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. |
| Find Code Related to an Internet-Draft or RFC |
|
|
Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and find such code. |
| Distributed Learning Architecture based on Edge-cloud Collaboration |
|
|
This document describes the distributed learning architecture based on edge-cloud collaboration. |
| WARP Streaming Format |
|
|
This document specifies the WARP Streaming Format, designed to operate on Media Over QUIC Transport. |
| Computing-Aware Traffic Steering (CATS) Using LISP |
|
| draft-kjsun-cats-lisp-01.txt |
| Date: |
22/01/2024 |
| Authors: |
Sun Kj, Tran Ngoc, Ha-Duong Phung, Younghan Kim |
| Working Group: |
Individual Submissions (none) |
|
This document describes the usage of Locator/ID Separation Protocol (LISP) as a solution to implement Computing-Aware Traffic Steering (CATS). How LISP meets CATS requirements and how it fits to the control plane and data plane of CATS framework are presented. |
| QUIC Bandwidth Delay Product Tokens |
|
|
This document describes a method to store previously calculated Congestion Control parameters on a QUIC client to allow additional capacity on high Bandwidth Delay Product paths to be used with Careful Resume. Discussion 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/theenbyperor/quic-bdp-token. |
| SPICE Metadata Discovery |
|
|
Entities interested in digital credentials need to express and discover preferences for working with them. Before issuance, holders need to discover what credentials are supported, and issuers need to discover if a holder's wallet is safe enough to store their credentials. Before presentation, holder's need to discovery verifier's encryption keys, and which presentation formats a verifier supports. After presentation, verifiers need to discover any new key material or status changes related to credentials. This document enables issuers, holders and verifiers to discover supported protocols and formats for keys, claims, credentials and proofs. |
| The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO |
|
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
|
|
| |
| UDP-based Transport for Configured Subscriptions |
|
| draft-ietf-netconf-udp-notif-12.txt |
| Date: |
21/01/2024 |
| Authors: |
Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente |
| Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based protocol for YANG notifications to collect data from network nodes. A shim header is proposed to facilitate the data streaming directly from the publishing process on network processor of line cards to receivers. The objective is to provide a lightweight approach to enable higher frequency and less performance impact on publisher and receiver processes compared to already established notification mechanisms. |
| YANG model for NETCONF Event Notifications |
|
|
This document defines the YANG model for NETCONF Event Notifications. The definition of this YANG model allows the encoding of NETCONF Event Notifications in YANG compatible encodings such as YANG-JSON and YANG-CBOR. |
| IPv4 routes with an IPv6 next hop |
|
|
We propose "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. We describe the technique, and discuss its operational implications. { Editor note: This document was originally published as draft- chroboczek-int-v4-via-v6, and later renamed to draft-chroboczek- intarea-v4-via-v6 . } |
| Chunked Oblivious HTTP Messages |
|
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. |
|
|
| |
| YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol |
|
| draft-ietf-alto-oam-yang-17.txt |
| Date: |
19/01/2024 |
| Authors: |
Jingxuan Zhang, Dhruv Dhody, Kai Gao, Roland Schott, Qiufang Ma |
| Working Group: |
Application-Layer Traffic Optimization (alto) |
|
This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. |
| Requirements for Reliable Wireless Industrial Services |
|
|
This document provides an overview of the communication requirements for handling reliable wireless services in the context of industrial environments. The aim of the draft is to raise awareness of the communication requirements of current and future wireless industrial services; how they can coexist with wired infrastructures; the key drivers for reliable wireless integration; the relevant communication requirements to be considered; the current and future challenges arising from the use of wireless services; and the potential benefits of wireless communication. |
| (strong) AuCPace,an augmented PAKE |
|
|
This document describes AuCPace which is an augmented PAKE protocol for two parties. The protocol was tailored for constrained devices and smooth migration for compatibility with legacy user credential databases. It is designed to be compatible with any group of both prime- and non-prime order and comes with a security proof providing composability guarantees. |
| OAM for LPWAN using Static Context Header Compression (SCHC) |
|
|
This document describes how SCHC can be used to efficiently perform basic Operation, Administration and Maintenance (OAM) on Low Power Wide Area Networks (LPWANs) by compressing ICMPv6/IPv6 headers, or by shielding the LPWAN network and the Device from undesirable ICMPv6 traffic. This document specifies additional behavior for SCHC [RFC8724] and extends the YANG Data Model defined in [RFC9363]. |
| Safe(r) Limited Domains |
|
|
There is a trend towards documents describing protocols that are only intended to be used within "limited domains". Unfortunately, these drafts often do not clearly define how the boundary of the limited domain is established and enforced, or require that operators of these limited domains //perfectly// implement filters to protect the rest of the Internet from these protocols. In addition, these protocols sometimes require that networks that are outside of (and unaffiliated with) the limited domain explicitly implement filters in order to protect their networks if these protocols leak outside of the limited domain. This document discusses the concepts of "fail-open" versus "fail- closed" protocols and limited domains, and provides a mechanism for designing limited domain protocols that are safer to deploy. |
|
|
| |
| A YANG Data Model for OSPF Segment Routing for the MPLS Data Plane |
|
|
This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing for the MPLS data plane. |
| Area Proxy for IS-IS |
|
|
Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. |
| Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication |
|
|
RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data. |
| SM2 Digital Signature Algorithm for DNSSEC |
|
|
This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC). This draft is an independent submission to the RFC series, and does not have consensus of the IETF community. |
| BGP extensions for BIER-TE |
|
|
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [RFC8279]. This document describes BGP extensions for advertising the BIER-TE specific information. |
| SID as source address in SRv6 |
|
|
In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. |
| RPKI Publication Server Best Current Practices |
|
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. |
| Policing Caused Jitter Control Mechanism |
|
|
A mechanism to eliminate jitter caused by policing delay is described. It needs to be used in combination with a scheduling mechanism that provides low jitter for the transport path, and ultimately provides a low jitter guarantee for the application flow. |
| Delay Options |
|
|
This document introduces new IPv6 options for HBH or DOH Options header, to carry delay related information for deterministic forwarding. |
| Some Key Terms for Incident Management |
|
|
This document sets out some key terms that are fundamental to a common understanding of Incident Management. The purpose of this document is to bring clarity to discussions and other work related to Incident Management in particular YANG models and management protocols that report, make visible, or manage incidents. |
| NTP Over PTP |
|
|
This document specifies a transport for the Network Time Protocol (NTP) client-server and symmetric modes using the Precision Time Protocol (PTP) to enable hardware timestamping on network interface controllers which can timestamp only PTP messages and enable corrections in PTP transparent clocks. |
|
|
| |
| FFV1 Video Coding Format Version 4 |
|
| draft-ietf-cellar-ffv1-v4-22.txt |
| Date: |
17/01/2024 |
| Authors: |
Michael Niedermayer, Dave Rice, Jerome Martinez |
| Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. |
| Extended Communities Derived from Route Targets |
|
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. |
| The Proximate Location Claim |
|
|
The Entity Attestation Token (EAT) is an extensible attestation version of a CBOR Web Token (CWT). EAT defines a location claim, but does not define a proximate location claim. This document proposes a claim in which an attester can relay detected relative location of a target. |
| JOSE algorithms for ECDH-MAC-based signatures |
|
|
This specification defines a JSON Web Algorithm for JOSE, that uses a combination of key agreement and MAC to construct a signature-like mechanism. |
| SRv6 for Redundancy Protection |
|
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability of service transmission in Segment Routing network. The mechanism uses the "Live-Live" methodology, with the aim of enhancing the functionalities of Segment Routing over IPv6. Inspired by DetNet Packet Replication and Packet Elimination functions, this document introduces two new Segments to provide replication and elimination functions on specific network nodes by leveraging SRv6 Segment programming capabilities. |
|
|
| |
| Key Provisioning for Group Communication using ACE |
|
| draft-ietf-ace-key-groupcomm-18.txt |
| Date: |
16/01/2024 |
| Authors: |
Francesca Palombini, Marco Tiloca |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. |
| Removing Expiration Notices from Internet-Drafts |
|
|
The long-standing policy of requiring that Internet-Drafts bear an expiration date is no longer necessary. This document removes requirements for expiration for Internet-Drafts from RFC 2026/BCP 9 and RFC 2418/BCP 25. In place of expiration, this document introduces Internet-Drafts being labeled "active" and "inactive" in the IETF tooling. |
| IS-IS Extension to Advertise SRv6 SIDs using SID Block |
|
|
This document proposes a simplified method to advertise SRv6 SIDs in IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs within the address range of a Locator. When a SID is assigned from the SID Block, it is described by an index based on the SID Block, instead of the whole 128-bit IPv6 address. |
| XML to JSON conversion rules for RESTful EPP |
|
|
This document describes the rules for converting an EPP [RFC5730] XML message to a JSON [RFC8259] message for use with RESTful EPP [REF-TO- REPP-HERE]. |
| Topology Independent Fast Reroute using Segment Routing |
|
|
This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two connected networks using a link-state IGP. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. |
|
|
| |
| The DNS Zone Version (ZONEVERSION) Option |
|
|
The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The Serial field from the Start Of Authority (SOA) resource record is a good example of a zone's version, and the only one defined by this specification. Additional version types may be defined by future specifications. Including zone version data in a response simplifies and improves the quality of debugging and and diagnostics since the version and the data are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the NSID option. |
| ISP Location in DNS Queries |
|
|
Nowadays, many authoritative servers support GeoIP feature, they guess the client's geolocation by the client subnet of EDNS Client Subnet (ECS) or by the source IP address of DNS query, return tailor DNS response based on the client's geolocation. However, ECS raises some privacy concerns because it leaks client subnet information on the resolution path to the authoritative server. This document describes an improved GeoIP solution, defines an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, tries to find the right balance between privacy improvement and user experience optimization. EIL is defined to convey isp location < COUNTRY, AREA, ISP > information that is relevant to the DNS message. It will directly provide sufficient information for the GeoIP-enabled authoritative server as ECS, decide the response without guessing client's geolocation. |
| The IPv6 Tunnel Payload Forwarding (TPF) Option |
|
|
This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. |
| How is the Area Director Workload Made Up? |
|
|
Anecdotally, every IESG complains about the Area Director (AD) workload, and says that it takes the first full term to understand the job. Empirically, the AD workload is high sometimes causing backlogs in processing of Internet-Drafts and stressing the ADs. After some discussions in the GENDISPATCH working group and arising from an Internet-Draft postulating changes that might reduce the AD workload, several ADs reported some data on how they spent their time in a few weeks chosen at random. This document collates that data and presents it for information. This document does not attempt to draw any conclusions from the limited data currently available, and there is no intention to publish this document as an RFC. |
| The Entity Attestation Token (EAT) |
|
| draft-ietf-rats-eat-25.txt |
| Date: |
15/01/2024 |
| Authors: |
Laurence Lundblade, Giridhar Mandyam, Jeremy O'Donoghue, Carl Wallace |
| Working Group: |
Remote ATtestation ProcedureS (rats) |
|
An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. |
|
|
| |
| Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager |
|
|
Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator entity interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession and server authentication. |
| Free Lossless Audio Codec |
|
| draft-ietf-cellar-flac-14.txt |
| Date: |
14/01/2024 |
| Authors: |
Martijn van Beurden, Andrew Weaver |
| Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals without losing information in doing so (i.e., lossless). FLAC is free in the sense that its specification is open and its reference implementation is open-source. Compared to other lossless (audio) coding formats, FLAC is a format with low complexity and can be coded to and from with little computing resources. Decoding of FLAC has seen many independent implementations on many different platforms, and both encoding and decoding can be implemented without needing floating- point arithmetic. |
| LISP Mobile Node |
|
| draft-ietf-lisp-mn-15.txt |
| Date: |
14/01/2024 |
| Authors: |
Dino Farinacci, Darrel Lewis, David Meyer, Chris White |
| Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. |
| YANG Module Versioning Requirements |
|
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. |
| Support of Hostname and Sequencing in YANG Notifications |
|
|
This document specifies a new YANG module that augment the NETCONF Event Notification header to support hostname, Message Publisher ID and sequence numbers to identify from which network node and at which time the message was published. This allows the collector to recognize loss, delay and reordering between the publisher and the downstream system storing the message. |
| Export of On-Path Delay in IPFIX |
|
|
This document introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay on the IOAM transit and decapsulation nodes. |
|
|
| |
| ML-DSA for JOSE and COSE |
|
| draft-ietf-cose-dilithium-02.txt |
| Date: |
12/01/2024 |
| Authors: |
Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans |
| Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document describes JOSE and COSE serializations for ML-DSA, which was derived from Dilithium, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-204]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/post-quantum-cryptography) standardization process. |
| SLH-DSA for JOSE and COSE |
|
| draft-ietf-cose-sphincs-plus-02.txt |
| Date: |
12/01/2024 |
| Authors: |
Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans |
| Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document describes JOSE and COSE serializations for SLH-DSA, which was derived from SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme. This document does not define any new cryptography, only seralizations of existing cryptographic systems described in [FIPS-205]. Note to RFC Editor: This document should not proceed to AUTH48 until NIST completes paramater tuning and selection as a part of the PQC (https://csrc.nist.gov/projects/post-quantum-cryptography) standardization process. |
| IKEv2 Optional SA&TS Payloads in Child Exchange |
|
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| A Transaction Ledger Verifiable Structure for COSE Merkle Tree Proofs |
|
|
This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced by Trusted Execution Environments (TEEs) to provide stronger tamper-evidence guarantees. |
| Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
|
|
This document defines a usage of Datagram Transport Layer Security (DTLS) 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP DTLS chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re- authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP [RFC6083] and SCTP-AUTH [RFC4895]. |
| Stream Control Transmission Protocol (SCTP) DTLS Chunk |
|
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| Guidelines for Performing Safe Measurement on the Internet |
|
|
Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the internet, it can present risks to user privacy and safety. This document describes briefly those risks and proposes guidelines for ensuring that internet measurements can be carried out safely, with examples. |
|
|
| |
| Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer |
|
| draft-ietf-bier-pmmm-oam-15.txt |
| Date: |
11/01/2024 |
| Authors: |
Greg Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola |
| Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. |
| Partitioning as an Architecture for Privacy |
|
|
This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. |
| Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP |
|
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new BGP Router Capability Code to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. |
| External Trace ID for Configuration Tracing |
|
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. |
| Emergency Communication Services over Wi-Fi Access Networks |
|
|
This document introduces an approach to enable emergency services over Wi-Fi access networks. These services encompass emergency services such as 911 in North America, 112 in the European Union, and equivalent emergency services in other regulatory domains. The proposed approach aims to provide a comprehensive solution for supporting emergency communication across different regions and regulatory frameworks. Leveraging the legal framework and infrastructure of the OpenRoaming federation, this proposal aims to extend emergency calling capabilities to the vast number of OpenRoaming Wi-Fi hotspots that have already been deployed. The approach addresses critical challenges related to emergency calling, including discovery and authentication procedures for accessing networks that support emergency services, emergency access credentials, the configuration of emergency voice services, accurate location determination of the emergency caller, and call spofing. By providing a comprehensive solution, this proposal ensures that emergency communication services can be seamlessly and effectively supported within the IEEE 802.11-based Wi-Fi ecosystem leveraging Passpoint Profiles. |
| Raytime: Validating token expiry on an unbounded local time interval |
|
|
When devices are deployed in locations with no real-time access to the Internet, obtaining a trusted time for validation of time limited tokens and certificates is sometimes not possible. This document explores the options for deployments in which the trade-off between availability and security needs to be made in favor of availability. While considerations are general, terminology and examples primarily focus on the ACE framework. |
| Computing-Aware Traffic Steering (CATS) Using Segment Routing |
|
| draft-lbdd-cats-dp-sr-01.txt |
| Date: |
11/01/2024 |
| Authors: |
Cheng Li, Mohamed Boucadair, Zongpeng Du, John Drake |
| Working Group: |
Individual Submissions (none) |
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifier and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. |
| Blind BBS Signatures |
|
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/BasileiosKal/blind-bbs-signatures. |
| Transfer Digital Credentials Securely |
|
| draft-vinokurov-tigress-http-00.txt |
| Date: |
11/01/2024 |
| Authors: |
Dmitry Vinokurov, Yogesh Karandikar, Matthias Lerch, Alex Pelletier, Nick Sha |
| Working Group: |
Individual Submissions (none) |
|
Digital Credentials allow users to access Homes, Cars or Hotels using their mobile devices. Once a user has a Credential on a device, sharing it to others is a natural use case. Process of sharing credentials should be secure, privacy preserving and have a seamless user experience. To facilitate Credential sharing, a new transport is required. This document defines that new transport to meet unique requirements of sharing a Credential. |
|
|
| |
| Key Usage Limits for OSCORE |
|
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. |
| Deprecation of AS_SET and AS_CONFED_SET in BGP |
|
|
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it proscribes the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 and RFC 5065, and obsoletes RFC 6472. |
| PCE-initiated IP Tunnel |
|
|
This document specifies a set of extensions to PCEP to support PCE- initiated IP Tunnel to satisfy the requirement which is introduced in [I-D.li-spring-tunnel-segment]. The extensions include the setup, maintenance and teardown of PCE-initiated IP Tunnels, without the need for local configuration on the PCC. |
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs |
|
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path, while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. |
| Flowspec Indirection-id Redirect for SRv6 |
|
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| Cacheable OSCORE |
|
|
Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. |
| Generalized IPv6 Tunnel for QUIC |
|
|
This document defines a new encapsulation method for QUIC packet transmission based on IPv6 extension headers. This method enables QUIC packet transmission to easily inherit the extended functions of IPv6. |
| One Administrative Domain using BGP |
|
| draft-uttaro-idr-bgp-oad-03.txt |
| Date: |
10/01/2024 |
| Authors: |
Jim Uttaro, Alvaro Retana, Pradosh Mohapatra, Keyur Patel, Bin Wen |
| Working Group: |
Individual Submissions (none) |
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). |
| Partially Blind RSA Signatures |
|
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. |
| Linearized Matrix |
|
|
This document specifies Linearized Matrix (LM). LM is an extensible protocol for interoperability between messaging providers, using Matrix's (matrix.org (https://matrix.org)) decentralized room model. LM simplifies the Directed Acyclic Graph (DAG) persistence of Matrix while maintaining compatibility with non-linearized servers within a room. It does this by using a doubly-linked list of events/messages per room with hub and spoke fanout. LM's extensibility enables a wide range of transport protocol and end-to-end encryption possibilities. This document uses Matrix's room access control semantics supported by Messaging Layer Security (MLS), transported via HTTPS and JSON. The details of which server- to-server transport to use and what is put over MLS are replaceable. The threat model of LM does not place trust in a central owning server for each conversation. Instead, it defines a hub server which handles maintaining linearized room history for other servers in the room. This model permits transparent interconnection between LM servers and Matrix servers, in the same room. |
| Policy experts are IETF stakeholders |
|
|
The IETF's work has significance for communities concerned with societal, economic, and political outcomes, though barriers to engagement with the IETF exist for non-technical experts from these communities. This informational document introduces a problem statement and gap analysis of existing initiatives related to policy expert engagement in the IETF. It aims to be a resource for anyone interested in working to enable policy expert engagement in IETF standardisation. |
| A SAVI Solution for WLAN |
|
|
This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. |
| Some Refinements to Network Topologies (RFC8345) |
|
|
This draft provides a brief analysis of the current unidirectional point-to-point approach to modeling of the link in RFC8345, highlights why this is not sufficient and makes a proposal to enhance RFC8345 YANG to support multipoint uni/bi links. The two alternative enhancement approaches proposed are backward compatible. The enhancement is such that it provides a uniform solution to modeling all links that could, over time, replace the current unidirectional point-to-point approach. The rationale for the change is based on many years of practical experience, including challenges using RFC8345 in actual solution development, and insight gained through other standardisation efforts and deployments. |
| Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
|
|
This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. |
| Signaling Additional SRTP Context information via SDP |
|
|
This document specifies additional cryptographic attributes for signaling additional Secure Real-time Transport Protocol (SRTP) cryptographic context information via the Session Description Protocol (SDP) in alongside those defined by RFC4568. The SDP extension defined in this document address situations where the receiver needs to quickly and robustly synchronize with a given sender. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. |
| Explicit Forged Answer Signal |
|
|
This document describes that recursive resolver should give explict signal in the forged answer. Client could react more clearly based on the explict forged answer signal, to protect user on security and privacy. |
| Bicone Source Address Validation |
|
|
The primary design goal of source address validation (SAV) is avoiding improper block (i.e., blocking legitimate traffic) while maintaining directionality, especially in partial deployment scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions typically generate ingress SAV allowlist filters by using information related to customer cone. This document analyzes potential improper block problems of solely using allowlist filters. To minimize improper block, this document proposes Bicone SAV, which enhances the SAV technology by additionally using blocklist filters generated based on information related to provider cone. |
|
|
| |
| YANG Data Model for Automatic Multicast Tunneling |
|
| draft-ietf-mboned-amt-yang-01.txt |
| Date: |
09/01/2024 |
| Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Xuesong Geng, Vinod Nagaraj |
| Working Group: |
MBONE Deployment (mboned) |
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. |
| Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP |
|
|
This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path. |
| Flow Measurement in IPv6 Network |
|
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. |
| Multicast Extension for QUIC |
|
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. |
| Considerations for Protection of SR Networks |
|
|
This document describes the considerations for protection of Segment Routing (SR) networks. |
| Internet Wall |
|
|
To have a way to specify an URL that can retrieve contents that is available only after authentication |
| The OAuth 2.1 Authorization Framework |
|
| draft-ietf-oauth-v2-1-10.txt |
| Date: |
09/01/2024 |
| Authors: |
Dick Hardt, Aaron Parecki, Torsten Lodderstedt |
| Working Group: |
Web Authorization Protocol (oauth) |
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. |
| Updates for PCEPS: TLS Connection Establishment Restrictions |
|
|
Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data. |
| Human Readable ASPA Notation |
|
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key |
|
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with a combination of a certificate and an external pre-shared key (PSK). |
|
|
| |
| TLS Extension for DANE Client Identity |
|
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. |
| Methods for Detection and Mitigation of BGP Route Leaks |
|
|
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. |
| REST API Linked Data Keywords |
|
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| Distributed Flow Measurement in IPv6 |
|
|
In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller. |
| Static Multicast Distribution Trees |
|
|
This document specifies the Static Provision of Multicast route as an alternate to Layer 3 Multicast protocols like PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM SSM (Source-Specific Multicast), or PIM BIDI (Bidirectional). It works like a standalone Multicast Route provisioning feature that can interoperate with other dynamic Multicast protocols like PIM-SM or with L2 protocols like IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery). This feature can function with/without the use of Unicast Routing Protocols to build the Multicast tree. |
| Views and View Addresses for Secure Asset Transfer |
|
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to-end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. |
| Protocol for Requesting and Sharing Views across Networks |
|
| draft-ramakrishna-satp-data-sharing-01.txt |
| Date: |
08/01/2024 |
| Authors: |
Venkatraman Ramakrishna, Vinayaka Pandit, Ermyas Abebe, Sandeep Nishad, Dhinakaran Vinayagamurthy |
| Working Group: |
Individual Submissions (none) |
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. |
| Integrating the Alternate-Marking Method into In Situ Operations,Administration,and Maintenance (IOAM) |
|
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. |
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT |
|
| draft-ietf-pce-pcep-ifit-04.txt |
| Date: |
08/01/2024 |
| Authors: |
Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola |
| Working Group: |
Path Computation Element (pce) |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. |
|
|
| |
| REST API Media Types |
|
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. |
| Metadata Query Protocol |
|
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. |
| SAML Profile for the Metadata Query Protocol |
|
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.21. |
| Encoding Network Slice Identification for SRv6 |
|
|
This document describes a method to encode network slicing identifier within SRv6 domain. |
| Path MTU (PMTU) for Segment Routing (SR) Policy |
|
|
This document defines the Path MTU (PMTU) for Segment Routing (SR) Policy (called SR-PMTU). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU for SR Policy including the link MTU collection, the SR-PMTU computation, the SR-PMTU enforcement, and the handling behaviours on the headend. |
| Segment Routing based Solution for Hierarchical IETF Network Slices |
|
|
This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. |
| An SR-TE based Solution For Computing-Aware Traffic Steering |
|
|
Computing-aware traffic steering (CATS) is a traffic engineering approach [I-D.ietf-teas-rfc3272bis] that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. Various relevant metrics may be used to enforce such computing-aware traffic steering policies.It is critical to meet different types of computing-aware traffic steering requirements without disrupting the existing network architecture. In this context, this document proposes a computing-aware traffic steering solution based on the SR- TE infrastructure of the current traffic engineering technology to reduce device resource consumption and investment and meet the requirements for computing-aware traffic steering of network devices. |
| Advertise NRP Group extensions for IGP |
|
|
Network slicing provides the ability to partition a physical network into multiple isolated logical networks of varying sizes,structures, and functions so that each slice can be dedicated to specific services or customers. A Network Resource Partition (NRP) is a collection of resources in the underlay network. Each NRP is used as the underlay network construct to support one or a group of IETF network slice services. This document describes an IGP mechanism that is used to advertise a large number of NRPs into a smaller number of NRP groups. |
| Transparency Tokens |
|
|
When professionals travel for business, they carry identity documents, such as passports, employer related payment capabilites, such as corporate credit cards, and security keys that might be used for both personal or professional reasons, such as hotel or car keys. These credentials might be stored in a purse, briefcase or wallet. Digital storage systems struggle to support the various credential formats, physical proximity and remote presentation protocols, and assurance capabilities needed to enable international business. Device capabilities, cost and power consumption can preclude access and adoption of digital credentials, or exclude communities that require higher than normal privacy, sustainability, or availability guarantees. This specification describes a scalable solution to digital credentials, that is market friendly, transport agnostic, privacy oriented, and accountable to users of digital credentials above all other stakeholders. |
| AAA for Hierarchical Network Slices |
|
|
This document describes an enhanced AAA mechanism for hierarchical network slice service when users access to the network and use the network slice resources of different SLA levels. |
|
|
| |
| DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) |
|
|
DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. |
| DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6 |
|
|
This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks. |
| Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP |
|
|
This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. |
| Use Cases for Parent SR Policy |
|
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is dynamic, explicit or composite. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment. |
| Intra-domain SAVNET method |
|
|
This document proposes a method of Source Address Validation in Intra-domain, which can be applied to OSPF and IS-IS protocols. By extending IGP and adding the protocol calculation procedure, the SAV rule can be accurately calculated to realize the source address verification. |
| An Overview of Energy-related Effort within the IETF |
|
|
This memo provides an overview of work performed by or proposed within the IETF related to energy and/or green: awareness, management, control or reduction of consumption of energy, and sustainability as it related to the IETF. This document is written to help those unfamiliar with that work, but interested in it, in the hope to raise more interest in energy- related activities within the IETF, such as identifying gaps and investigating solutions as appropriate. This document captures work until 12/2022, at which time the "IAB workshop on Environmental Impact of Internet Applications and Systems" revived interest and triggered new work in the topic within the IETF/IRTF. |
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
|
| draft-eckert-detnet-tcqf-05.txt |
| Date: |
05/01/2024 |
| Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren, Fan Yang |
| Working Group: |
Individual Submissions (none) |
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. |
| Deterministic Networking (DetNet) Controller Plane - VPFC Planning Information Model Based on VPFP in Scaling Deterministic Networks |
|
| draft-guo-detnet-vpfc-planning-03.txt |
| Date: |
05/01/2024 |
| Authors: |
Daorong Guo, Guangliang Wen, Kehan Yao, Quan Xiong, Guoyu Peng, YOU Xuejun, zhushiyin |
| Working Group: |
Individual Submissions (none) |
|
The cycle-based queuing and forwarding mechanisms are an effective method to ensure that the transmission has a definite upper bound of jitter, as well as latency. The prerequisite for this method is to ensure that queuing resources do not conflict. In scaling deterministic networks, how to avoid the queuing resources conflict of this method is an open problem. This document proposes the information model of planning virtual periodic forwarding channel (VPFC) based on virtual periodic forwarding path (VPFP). The solution can solve the queuing resources conflict of cycle-specified queuing and forwarding in nonlinear topology domain, ensuring the bounded latency of DetNet flow in the same periodic forwarding domain. |
| Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
|
| draft-eckert-detnet-glbf-02.txt |
| Date: |
05/01/2024 |
| Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| Working Group: |
Individual Submissions (none) |
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. |
| SRv6 Segment List optimization |
|
|
This document introduces an optimization method for segment list arrangement to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. |
| Problem statements and requirements of L2 CATS |
|
|
The computing intensive parts of the customer premise equipment have been decoupled and migrated to the cloud, therefore the thin CPE remaining at customer premise needs to access its “avatar” virtual CPE in the cloud which could be deployed in multiple edge computing sites. This draft will illustrate a use case of L2 traffic steering in terms of dynamic computing and networking resource status, together with requirements for CATS as well as solution consideration with regard to particularly the difference from the L3 routing framework. |
| PCEP Extension to Support SRv6 Segment List optimization |
|
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for optimizing the arrangement of segment lists to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. |
| Deterministic Networking (DetNet) Data Plane - Flow interleaving for scaling detnet data planes with minimal end-to-end latency and large number of flows. |
|
|
This memo explain requirements, benefits and feasibility of a new DetNet service function tentatively called "flow interleaving". It proposes to introduce this service function into the DetNet architecture. Flow interleaving can be understood as a DetNet equivalent of the IEEE TSN timed gates. Its primary role is intended to be at the ingress edge of DetNet domains supporting higher utilization and lower bounded latency for flow aggregation (interleaving of flows into a single flow), as well as higher utilization and lower bounded latency for interleaving occurring in transit hops of the DetNet domain in conjunction with in-time per-hop bounded latency forwarding mechanisms. |
| Definition for Aggregated BMP Route Monitoring Message |
|
|
This document proposes a aggregated BMP route monitoring message. It can compress multiple BMP route monitoring messages into one aggregated BMP route monitoring message to reduce the amount of reported BMP route monitoring messages and reduce network overhead. This document updates RFC 7854 by adding new BMP Messages type. |
| Clarification to processing Key Usage values during CRL validation |
|
|
RFC 5280 defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. This profile requires that certificates which certify keys for signing CRLs contain the key usage extension with the cRLSign bit asserted. Additionally, RFC 5280 defines steps for the validation of CRLs. While there is a requirement for CRL validators to verify that the cRLSign bit is asserted in the keyUsage extension of the CRL issuer's certificate, there is no requirement for validators to verify the presence of the keyUsage extension itself. The lack of this requirement may manifest in an issue in some Public Key Infrastructures where a CRL issuer who has been certified by a Certification Authority to issue CRLs on its behalf can sign CRLs using a key that has not been certified for signing CRLs. This document specifies an enhancement to the CRL validation process to explicitly require the presence of the keyUsage extension to resolve this issue. |
| SADCDN Video Optimization Requirements |
|
|
These are the requirements for the "Video Optimization" use-case for the SADCDN topic, which broadly speaking seeks to optimize video playback experience in mobile networks by cooperative communication between video content providers and the providers of network services to end users. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mjoras/sadcdn-video-optimization-requirements. |
|
|
| |
| BGP Logical Link Discovery Protocol (LLDP) Peer Discovery |
|
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. |
| Problems and Requirements of Satellite Constellation for Internet |
|
|
This document presents the detailed analysis about the problems and requirements of satellite constellation used for Internet. It starts from the satellite orbit basics, coverage calculation, then it estimates the time constraints for the communications between satellite and ground-station, also between satellites. How to use satellite constellation for Internet is discussed in detail including the satellite relay and satellite networking. The problems and requirements of using traditional network technology for satellite network integrating with Internet are finally outlined. |
| A Mechanism for Encoding Differences in Paired Certificates |
|
|
This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to construct the paired certificate and perform certification path validation using the constructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. |
| Ping Path Consistency over SRv6 |
|
|
In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. |
| MIMI Portability |
|
|
This document describes MIMI Portability mechanisms. |
| MIMI Attachments |
|
|
This document describes MIMI Attachments. |
| CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs) |
|
|
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. This specification extends this functionality to CBOR Web Tokens (CWTs). |
| OpenPGP |
|
|
This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). |
| Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
|
|
This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798 which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768 which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. |
| Secure Asset Transfer (SAT) Interoperability Architecture |
|
| draft-ietf-satp-architecture-02.txt |
| Date: |
04/01/2024 |
| Authors: |
Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna |
| Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. |
| Datagram PLPMTUD for UDP Options |
|
|
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across the network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required. |
|
|
| |
| The ALTO Transport Information Publication Service |
|
| draft-ietf-alto-new-transport-22.txt |
| Date: |
03/01/2024 |
| Authors: |
Kai Gao, Roland Schott, Y. Yang, Lauren Delwiche, Lachlan Keller |
| Working Group: |
Application-Layer Traffic Optimization (alto) |
|
The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource one at a time. ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly, concurrently (non-blocking) request (pull) specific incremental updates using native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1. |
| DTN Bundle Protocol Security (BPSec) COSE Context |
|
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| BGP BFD Strict-Mode |
|
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. It is referred to as BGP BFD "strict-mode". BGP BFD strict-mode will be supported when both the local speaker and its remote peer are BFD strict-mode capable. |
| Alternate Marking Deployment Framework |
|
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. |
| Secure IP Binding Synchronization via BGP EVPN |
|
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. |
| Persistent Symmetric Keys in OpenPGP |
|
|
This document defines new algorithms for the OpenPGP standard (RFC4880) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for authentication with hash-based message authentication codes (HMAC). This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. |
| WebTransport over WebSocket |
|
|
WebTransport [OVERVIEW], a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket [WEBSOCKET], offering WebTransport capabilities similar to the HTTP/2 variant [WEBTRANSPORT-H2]. It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket [WEBSOCKET]. |
|
|
| |
| EVPN BUM Using BIER |
|
| draft-ietf-bier-evpn-14.txt |
| Date: |
02/01/2024 |
| Authors: |
Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan |
| Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document specifies protocols and procedures for forwarding broadcast, unknown unicast, and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). |
| Simplemux. A generic multiplexing protocol |
|
|
The high amount of small packets present in nowaday's networks results in a low efficiency, as the size of both the headers and the payload in these packets can be comparably large, often falling within the same order of magnitude. In some situations, multiplexing (i.e. aggregating) a number of small packets into a bigger one is desirable to improve the efficiency. For example, a number of small packets can be sent together between a pair of machines if they share a common network path. This may happen between machines in different locations or even inside a datacenter with a number of servers hosting virtual machines. The traffic profile can be shifted from small to larger packets, thus reducing the network overhead and the number of packets per second to be managed by intermediate devices. This document describes Simplemux, a protocol able to encapsulate a number of packets belonging to different protocols into a single packet. Small headers (separators) are added at the beginning of each multiplexed packet, including some flags, the packet length and a "Protocol" field. The presence of this "Protocol" field allows it to aggregate packets belonging to any protocol (the "multiplexed packets"), in a single packet belonging to other (or the same) protocol (the "tunneling protocol"). To reduce the overhead, the size of the multiplexing headers is kept very low (it may be a single byte when multiplexing packets of small size). |
| Kyber Post-Quantum KEM |
|
|
This memo specifies a preliminary version ("draft00", "v3.02") of Kyber, an IND-CCA2 secure Key Encapsulation Method. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg- schwabe-kyber.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/draft-schwabe-cfrg-kyber. |
| Middle Ware Facilities for CATS |
|
|
This draft proposes a method to perceive and process the running status of computing resources by introducing a logical Middle Ware facility, aiming to avoid directly reflecting continuous and dynamic computing resource status in the network domain, match service requirements and instance conditions, and ultimately achieve computing aware traffic steering and be applicable to various possible scheduling strategies. |
| Microloop Prevention in a Hierarchical Segment Routing Solution for CATS |
|
|
Considering computing and networking is quite different in terms of resource granularity as well as their status stability, a hierarchical segment routing is proposed and introduced as an end-to- end CATS process. However, it brings about potential problems as illustrated in [I-D.yuan-cats-end-to-end-problem-requirement]. In order to solve the mentioned problems and to improve and perfect a hierarchical solution, corresponding aggregation methods are discussed and hierarchical entries are proposed in this draft. |
| RDAP Extension for DNS Time-To-Live (TTL Values) |
|
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. 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/rdap-ttl-extension. |
| Simplemux Blast flavor |
|
|
Many utilities are nowadays connected via dedicated networks, but the trend toward a fully IP network is gaining more traction in some sectors (e.g. electric power). In some use cases, although it would be desirable to avoid the use of IP networks, this may prove unavoidable. Consequently, equipment is linked to extensive communication networks, the performance of which cannot be fully controlled or known. Some utilities that are not connected to a dedicated network may use public wireless networks, which present certain degree of variability of some parameters (delay, jitter, packet loss, and bandwidth limits). Considering the importance of receiving packets with a low delay, this document presents a solution for using tunnels to send frames or packets between remote facilities, with a certain degree of redundance. This can be useful in some use cases as e.g. the sending of event-driven field commands between eletric substations. In some cases, these messages can be very critical, and their loss or delay can make the difference between a blackout and a simple outage. Considering the high redundancy of the protocol, its use must be restricted to traffic flows which require very low delay to control critical equipment. |
| Cryptovolense |
|
|
Digital presentations enable a holder of digital credentials to present proofs to a verifier. Using QR Codes for digital presentations introduces challenges regarding maximum transmission size, error correction and confidentiality. This document describes a generic optical transmission protocol suitable for digital credential presentations. |
|
|
| |
| Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
|
| draft-ietf-cats-usecases-requirements-02.txt |
| Date: |
01/01/2024 |
| Authors: |
Kehan Yao, Dirk Trossen, Mohamed Boucadair, Luis Contreras, Hang Shi, Yizhou Li, Shuai Zhang, Qing An |
| Working Group: |
Computing-Aware Traffic Steering (cats) |
|
Distributed computing is a tool that service providers can use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities aids support of services such as computationally intensive and delay sensitive services. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response times. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to best meet the customer's expectations and deliver the requested service. |
| SR-MPLS / SRv6 Transport Interworking |
|
| draft-bonica-spring-srv6-end-dtm-11.txt |
| Date: |
01/01/2024 |
| Authors: |
Shraddha Hegde, Parag Kaneriya, Ron Bonica, Shaofu Peng, Greg Mirsky, Zheng Zhang, Bruno Decraene, Dan Voyer, Swadesh Agrawal |
| Working Group: |
Individual Submissions (none) |
|
This document describes procedures for interworking between an SR- MPLS transit domain and an SRv6 transit domain. Each domain contains Provider Edge (PE) and Provider (P) routers. Area Border Routers (ABR) provide connectivity between domains. The procedures described in this document require the ABR to carry a route to each PE router. However, they do not required the ABR to carry service (i.e., customer) routes. In that respect, these procedures resemble L3VPN Interprovider Option C. Procedures described in this document support interworking for global IPv4 and IPv6 service prefixes. They do not support interworking for VPN services prefixes where the SR-MPLS domain uses MPLS service labels. |
| RIFT in Dragonfly Topologies |
|
|
RIFT extensions for dragonfly topologies. |
| OpenPGP Literal Data Metadata Integrity |
|
|
This document specifies a method for ensuring the integrity of file metadata when signed using OpenPGP. |
| A lightweight DNS delegation confirmation protocol |
|
|
Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. |
| A lightweight DNS delegation confirmation protocol |
|
|
Delegation occurs when an NS record is added in the parent zone for the child origin. In the current DNS delegation mechanism, a delegated zone/child zone (see Section1.1 for definition of delegated zone) can specify any NS records at the zone apex without requiring confirmation from the zone maintaining Glue records of the NS record. Recently, new types of attacks that exploit this flaw have been discovered. This draft suggests a protocol-level solution for DNS delegation confirmation to reduce the risk of these attacks. |
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. |
|
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. |