|
|
| |
| Key Provisioning for Group Communication using ACE |
|
| draft-ietf-ace-key-groupcomm-19.txt |
| Date: |
30/04/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. |
| A Framework for Computing-Aware Traffic Steering (CATS) |
|
| draft-ietf-cats-framework-02.txt |
| Date: |
30/04/2024 |
| Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes. |
| Advertising Segment Routing Policies in BGP |
|
| draft-ietf-idr-sr-policy-safi-04.txt |
| Date: |
30/04/2024 |
| Authors: |
Stefano Previdi, Clarence Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain |
| Working Group: |
Inter-Domain Routing (idr) |
|
A Segment Routing (SR) Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI to advertise a candidate path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. |
| LISP L2/L3 EID Mobility Using a Unified Control Plane |
|
| draft-ietf-lisp-eid-mobility-14.txt |
| Date: |
30/04/2024 |
| Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| Enhanced Topology Independent Loop-free Alternate Fast Re-route |
|
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| A YANG Network Data Model of Network Inventory Software Extensions |
|
|
The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for software-enabled NEs (e.g., controllers, virtual network functions (VNFs)) and software components (e.g., platform operating system (OS), software-patch). |
| QUIC Acknowledgment Frequency |
|
|
This document specifies an extension to QUIC that enables an endpoint to request its peer change its behavior when sending or delaying acknowledgments. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. |
| 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. |
|
|
| |
| EVPN control plane for Geneve |
|
|
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by Network Virtualization Edges (NVEs) to express Geneve tunnel option TLV(s) supported in the transmission and/or reception of Geneve encapsulated data packets. |
| BGP Usage for SD-WAN Overlay Networks |
|
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. |
| Related Certificates for Use in Multiple Authentications within a Protocol |
|
|
This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. |
| IS-IS Distributed Flooding Reduction |
|
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any topology with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in slower convergence times and higher resource utilization to process and discard the superfluous copies. Distributed algorithms that restrict the amount of flooding performed can be constructed, as long as they result in a flooding subgraph connecting all nodes on the network in terms of flooding still. Such algorithms can reduce resource utilization significantly, while improving convergence performance. We denote such algorithm as "distributed flooding prunners" (or "prunner" for short) while requiring them to follow some simple, additional rules. The rules presented in detail later allow to deploy mix of nodes any prunning algorithm and multiple prunners at the same time if necessary while ensuring correct flood coverage for the whole network. Additionally, node by node migration, without flag day, from one algorithm to another if necessary is possible. And assuming the algorithms are behaving correctly, the blast radius on algorithm change is normally contained to a single node performing the switch and obviously the convergence of an algorithm on introduction or removal of node running such algorithm. One such algorithm (modification of previous art), deployable even without configuration, is described in this document. Beside reducing the extraneous copies, the proposed solution does "load- balance" flooding across different possible paths in the network to prevent build up of flooding hot-spots. |
| DLEP Radio Quality Extension |
|
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. |
| DLEP Radio Band Extension |
|
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the frequency bands used by the radio. |
| DLEP Radio Channel Utilization Extension |
|
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. |
| PCEP Extension to Support Signaling Candidate Path Threshold Constraints of SR Policy |
|
|
This document defines the extension of PCEP to signal the threshold and metric constraint parameters of candidate paths for SR Policy to support flexible path selection. |
| A Network Inventory Topology Model |
|
|
This document defines a YANG model for network inventory topology to correlate the network inventory data with the general topology model to form a base underlay network, which can facilitate the mapping and correlation of the layer (e.g. Layer 2, Layer3) topology information above to the inventory data of the underlay network for agile service provisioning and network maintenance analysis. |
| DNS IPv6 Transport Operational Guidelines |
|
|
This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. It expands on RFC 3901 by now suggesting authoritative and iterative resolvers to operate on both IPv4 and IPv6. This document obsoletes RFC3901. (if approved) Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/momoka0122y/draft-dnsop-3901bis. |
| Measurement Method for Bandwidth of SRv6 Forwarding Path |
|
|
This document proposes a method for measuring the actual bandwidth of SRv6 forwarding paths. Carrying the bandwidth information from bottleneck nodes along the packet path in the IPv6 extension header of data packets or active measurement packets, the head node and controller can obtain the actual minimum available bandwidth of the forwarding path in real-time. |
| Deprecating Insecure Practices in RADIUS |
|
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates insecure uses of RADIUS, and mandates the use of secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give many recommendations for practices which increase security and privacy. |
| The SSLKEYLOGFILE Format for TLS |
|
|
A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. |
|
|
| |
| DTN Management Architecture |
|
| draft-ietf-dtn-dtnma-14.txt |
| Date: |
28/04/2024 |
| Authors: |
Edward Birrane, Sarah Heiner, Emery Annis |
| Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices. This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over uni-directional links and other places where BP is the preferred transport. |
| BGP Flow Specification Version 2 |
|
| draft-ietf-idr-flowspec-v2-04.txt |
| Date: |
28/04/2024 |
| Authors: |
Susan Hares, Donald Eastlake, Chaitanya Yadlapalli, Sven Maduschke |
| Working Group: |
Inter-Domain Routing (idr) |
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. |
| MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
|
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute to be used in conjunction with the specific AFI/SAFI for IPv4 and IPv6. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| Subscription to Distributed Notifications |
|
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. |
| 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 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. |
| IRTF Code of Conduct |
|
|
This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and diversity of participation. Through this code of conduct, the IRTF will continue to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect |
| Identity Trust System |
|
|
This document describes the identity trust system, which is an open identity authentication system that requires no federation of authentication domains. It is based on a symmetric authentication protocol and a specific infrastructure based on trust in Identity Providers (IdPs). Below are the main components of the authentication process between two entities. |
| Use of UDP Options for Transmission of Large DNS Responses |
|
|
This document describes an experimental method for using UDP Options to facilitate the transmission of large DNS responses without the use of IP fragmentation or fallback to TCP. |
|
|
| |
| BGP Color-Aware Routing (CAR) |
|
|
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible NLRI model for both SAFIs that allow multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types, Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, Label Index and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Extended Community. |
| BGP Classful Transport Planes |
|
| draft-ietf-idr-bgp-ct-33.txt |
| Date: |
26/04/2024 |
| Authors: |
Kaliraj Vairavakkalai, Natrajan Venkataraman |
| Working Group: |
Inter-Domain Routing (idr) |
|
This document specifies a mechanism referred to as "Intent Driven Service Mapping". The mechanism uses BGP to express intent based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC 4364 procedures and follows RFC 8277 NLRI encoding is defined to advertise underlay routes with its identified class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. |
| BGP Signaled MPLS Namespaces |
|
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| Inband Flow Analyzer |
|
| draft-kumar-ippm-ifa-08.txt |
| Date: |
26/04/2024 |
| Authors: |
Jai Kumar, Surendra Anubolu, John Lemon, Rajeev Manur, Hugh Holbrook, Anoop Ghanwani, Dezhong Cai, Heidi Ou, Yizhou Li, Xiaojun Wang |
| Working Group: |
Individual Submissions (none) |
|
Inband Flow Analyzer (IFA) records flow specific information from an end station and/or switches across a network. This document discusses the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes a transport-agnostic header definition that may be used for tunneled and non-tunneled flows alike. |
| 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. |
|
|
| |
| Per multicast flow Designated Forwarder Election for EVPN |
|
|
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[RFC8584] improves base line DF election by introducing HRW DF election. [RFC9251] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [RFC8584] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow). |
| DMARC Aggregate Reporting |
|
|
DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes [RFC7489]. |
| BGP CT - Adaptation to SRv6 dataplane |
|
|
This document specifies how the mechanisms for "Intent Driven Service Mapping" defined in [BGP-CT] are applied to SRv6 dataplane. The extensions needed for SRv6 dataplane operations are specified. Base procedures of BGP CT are followed unaltered. Illustration of how BGP CT procedures work in SRv6 dataplane is provided in this document. |
| Encapsulating IP in UDP |
|
| draft-xu-intarea-ip-in-udp-13.txt |
| Date: |
25/04/2024 |
| Authors: |
Xiaohu Xu, Hamid Assarpour, Shaowen Ma, Daniel Bernier, Darren Dukes, Shraddha Hegde, Yiu Lee, Fan Yongbing |
| Working Group: |
Individual Submissions (none) |
|
Existing IP-in-IP encapsulation technologies are not adequate for efficient load balancing of IP-in-IP traffic across IP networks. This document specifies additional IP-in-IP encapsulation technology, referred to as IP-in-UDP (User Datagram Protocol), which can facilitate the load balancing of IP-in-IP traffic across IP networks. |
| Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation |
|
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. The present version of this document is mostly a proof of concept, but was deemed useful to obtain initial feedback on the approach taken. |
| Aircraft to Anything AdHoc Broadcasts and Session |
|
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. |
| BGP Route Broker for Hyperscale SDN |
|
|
This document describes an optimized BGP route reflector mechanism, referred to as a BGP route broker, so as to use BGP-based IP VPN as an overlay routing protocol in a scalable way for hyperscale data center network virtualization environments, also known as Software- Defined Network (SDN) environments. |
| Route Target ORF |
|
|
This document defines a new Outbound Router Filter (ORF) type for BGP, referred to as "Route Target Outbound Route Filter", that can be used to perform route target based route filtering. |
| Application-aware Networking (APN6) Header Authentication |
|
| draft-liu-apn-header-auth-01.txt |
| Date: |
25/04/2024 |
| Authors: |
liuy619@chinaunicom.cn, Ran Pang, Changwang Lin, Mengxiao Chen |
| Working Group: |
Individual Submissions (none) |
|
This document proposes an authentication method to verify the application-aware networking (APN) header. |
| Export of GTP-U Information in IP Flow Information Export (IPFIX) |
|
|
This document introduces IP Flow Information Export Information Elements to identify information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| Fast Congestion Notification Packet (CNP) in RoCEv2 Networks |
|
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is similar to Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switches directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. |
|
|
| |
| CDNI Edge Control Metadata |
|
|
This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. |
| Group Communication for the Constrained Application Protocol (CoAP) |
|
|
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| The Messaging Layer Security (MLS) Extensions |
|
|
This document describes extensions to the Messaging Layer Security (MLS) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-extensions. |
| Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection |
|
|
This document describes how to use Simple Two-way Active Measurement Protocol (STAMP) test packets in combination with Hybrid Methods to perform Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. It also defines optional TLVs which are carried in STAMP test packets to enhance the STAMP based functions. Such extensions to STAMP enable performance measurement and collection at every node and link along a STAMP test packet's delivery path. |
| Epoch Markers |
|
|
This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. |
| Testing async submission |
|
|
This draft is submitted only to test the async api submission endpoint |
| Asset Lifecycle Management and Operations: A Problem Statement |
|
| draft-palmero-ivy-ps-almo-01.txt |
| Date: |
24/04/2024 |
| Authors: |
Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez |
| Working Group: |
Individual Submissions (none) |
|
This document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model. The primaty objectives for the problem statement document is to validate and proof that the framework can measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. |
| Data Model for Asset Lifecycle Management and Operations |
|
| draft-palmero-ivy-dmalmo-01.txt |
| Date: |
24/04/2024 |
| Authors: |
Marisol Palmero, Frank Brockners, Sudhendu Kumar, Camilo Cardona, Diego Lopez |
| Working Group: |
Individual Submissions (none) |
|
This document includes a data model for assets lifecycle management and operations. The primary objective of the data model is to measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset. This model is based on the information model introduced in "Asset Lifecycle Management and Operations: A Problem Statement" (ALMO) [I-D.draft-palmero-opsawg-ps-almo-00] IETF draft. |
| IPFIX Alternate-Marking Information |
|
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| BGP over TLS/TCP |
|
|
This document specifies the utilization of TCP/TLS to support BGP. |
| Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
|
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
|
| draft-ietf-spring-stamp-srpm-15.txt |
| Date: |
24/04/2024 |
| Authors: |
Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Richard Foote |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The procedure described is used for links, SR paths (including SR Policies and SR IGP Flexible Algorithm paths) as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. |
|
|
| |
| Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type |
|
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server of changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server. |
| Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks |
|
|
Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. |
| BGP Extension for Distributing CP Threshold Constraints of SR Policy |
|
|
This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. |
| EAT profile for Intel® Trust Domain Extensions (TDX) attestation result |
|
|
Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. |
| A Mechanism for X.509 Certificate Discovery |
|
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. |
| Extending ICMP for Node Identification |
|
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). |
| BGP Link State Extensions for Scalable Network Resource Partition |
|
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. |
| Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility |
|
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. |
|
|
| |
| VPOLL: Consensus Scheduling Component for iCalendar |
|
|
This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. |
| A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) |
|
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| IGP Unreachable Prefix Announcement |
|
|
In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. |
| Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes |
|
|
Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. Path Segment can be used in an SR over MPLS (SR-MPLS) data plane. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV and sub-TLV definitions for PSID. |
| Explicit Congestion Notification for the Stream Control Transmission Protocol |
|
|
This document describes the addition of the Explicit Congestion Notification (ECN) to the Stream Control Transmission Protocol (SCTP). |
| SRv6 Egress Protection in Multi-homed scenario |
|
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
|
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| Basic Support for IPv6 Networks Operating over 5G Vehicle-to-Everything Communications |
|
|
This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to the existing IPv6 protocol stack. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 in more complex 5G scenarios are not covered in this specification and are a subject for future work. |
| Intent-Based Network Management Automation in 5G Networks |
|
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| BGP SPF Extensions for Intra-domain SAVNET |
|
|
This document describes the BGP SPF protocol extension that is required for Source Address Validation in Intra-domain. By extending BGP SPF and adding the BGP SPF protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification. |
| Service Interworking between SRv6 |
|
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
|
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
|
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
|
|
| |
| Delay-based Metric Extension for the Babel Routing Protocol |
|
|
This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower latency links over higher latency ones. |
| Constrained Resource Identifiers |
|
| draft-ietf-core-href-15.txt |
| Date: |
21/04/2024 |
| Authors: |
Carsten Bormann, Henk Birkholz |
| Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –15 of this draft continues -14 by picking up // more comments, such as moving to a CRI scheme number registration // system based on unsigned numbers. This revision still contains // open issues and is intended to serve as a snapshot. |
| Structured Field Values for HTTP |
|
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document obsoletes RFC 8941. |
| LISP Map Server Reliable Transport |
|
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| Generic Multicast Router Election on LAN's |
|
|
When a host is connected to multiple multicast capable routers, each of these routers is a candidate to process the multicast flow for that LAN, but only one router should be elected to process it. This document proposes a generic multicast router election mechanism using Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) that can be used by any Multicast Overlay Signalling Protocol (MOSP). Having such generic election mechanism removes a dependency on Protocol Independent Multicast (PIM). |
| A Collaborative Framework for Cyberspace Governance: the Internet of Governance |
|
|
This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples. |
| EAT Attestation Results |
|
| draft-fv-rats-ear-03.txt |
| Date: |
21/04/2024 |
| Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov |
| Working Group: |
Individual Submissions (none) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| Integration of Speech Codec Enhancement Methods into the Opus Codec |
|
|
This document proposes a method for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| Resource Guarantee for SRv6 Policies |
|
|
This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list , the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. |
| An Application Layer Interface for Non-IP device control (NIPC) |
|
| draft-brinckman-nipc-01.txt |
| Date: |
21/04/2024 |
| Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| Working Group: |
Individual Submissions (none) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices. The described interface is extensible. This memo initially describes Bluetooth Low Energy and Zigbee as they are the most commonly deployed. |
| IGP Color-Aware Routing |
|
| draft-lin-lsr-igp-car-01.txt |
| Date: |
21/04/2024 |
| Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| Static Context Header Compression and Fragmentation for Zero Energy Devices |
|
|
This document describes the use of SCHC for very constraint devices. The use of SCHC will bring connectivity to devices with restrained use of battery and long delays. |
|
|
| |
| Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
|
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. |
| Constrained Application Protocol (CoAP) Performance Measurement Option |
|
| draft-ietf-core-coap-pm-02.txt |
| Date: |
19/04/2024 |
| Authors: |
Giuseppe Fioccola, Tianran Zhou, Massimo Nilo, Fabrizio Milan, Fabio Bulgarella |
| Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. |
| BGP SR Policy Extensions to Enable IFIT |
|
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. |
| TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences |
|
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/Augmented Reality (AR), live streaming can place a unique type of stress upon network resources. TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offer Replication-as- a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology in the way that it makes content distribution more accessible to more people by dramatically reducing the costs of replication. |
| Flexible Session Protocol |
|
|
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management |
| Using NETCONF over QUIC connection |
|
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF can be carried over various transports such as TCP, SSH or else. QUIC provides useful semantics for Network management and NETCONF in particular as a single connection can carry multiple requests over streams, enabling much better efficiency and performance for both peers. QUIC provides shorter handshake and includes TLS. QUIC is also more adaptable to more difficult environments such as those with long delays. This document describes how to use NETCONF over the QUIC transport protocol, named NETCONFoQUIC. |
| EDNS Presentation and JSON Format |
|
|
This document describes the textual and JSON representation formats of EDNS options. It also modifies the escaping rules of the JSON representation of DNS messages, previously defined in RFC8427. |
| Coordinated Congestion Management |
|
|
AI fabric is sensitive to bandwidth. Congestion management, including congestion control and load balancing, is a main method to fully utilize network resource. However, current congestion management mechanisms are not coordinated, which lead to throughput decreasing. This document provides a scheme to coordinate different congestion management mechanisms. It describes the design principle, behaviors of network switches and hosts in the scheme, and gives an example to show end-to-end procedure. |
| OpenPGP Hardware-Backed Secret Keys |
|
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored on a hardware device. |
| OAM for use in GENEVE |
|
| draft-ietf-nvo3-geneve-oam-10.txt |
| Date: |
19/04/2024 |
| Authors: |
Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti |
| Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. |
| An RDAP Extension for Geofeed Data |
|
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and link relation type for the associated link objects included in responses. |
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases |
|
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". |
| New Protocols Must Require TLS 1.3 |
|
|
TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Since TLS 1.3 use is widespread, new protocols must require and assume its existence. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |
|
|
| |
| Discovery for BRSKI variations |
|
|
This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators. |
| Task Extensions to iCalendar |
|
|
This document updates and defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. |
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) |
|
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. |
| Announcing Supported Authentication Methods in IKEv2 |
|
|
This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different type to authenticate each other. |
| ISP Dual Queue Networking Deployment Recommendations |
|
|
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment decisions are ultimately left to implementers. This document explores the potential implications of key deployment decisions and makes recommendations for those decisions that may help drive adoption. |
| MNA for Performance Measurement with Alternate Marking Method |
|
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| Enforcing end-to-end delay bounds via queue resizing |
|
|
This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. |
| Ethernet VPN Signalling Extensions for Bit-stream VPWS |
|
|
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). |
| LDP Extensions to Support Private Line Emulation (PLE) |
|
|
This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks. |
| Security Considerations for Computing-Aware Traffic Steering |
|
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing node as well as workflows of CATS procedures. This document describes various threats and security concerns related to CATS networks and existing approaches to solve these threats. |
| Representing metadata annotations in YANG-CBOR |
|
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS |
|
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| Detailed Software Supply Chain Uses Cases for SCITT |
|
| draft-ietf-scitt-software-use-cases-03.txt |
| Date: |
18/04/2024 |
| Authors: |
Henk Birkholz, Yogesh Deshpande, Dick Brooks, Bob Martin, Brian Knight |
| Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document includes a collection of representative Software Supply Chain Use Cases. These use cases aim to identify software supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. |
| Circuit Style Segment Routing Policies |
|
| draft-ietf-spring-cs-sr-policy-02.txt |
| Date: |
18/04/2024 |
| Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). |
| Workload Identity in a Multi System Environment (WIMSE) Architecture |
|
| draft-ietf-wimse-arch-00.txt |
| Date: |
18/04/2024 |
| Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |
|
|
| |
| JMAP Sharing |
|
|
This document specifies a data model for sharing data between users using JMAP. Future documents can reference this document when defining data types to support a consistent model of sharing. |
| Proxying Ethernet in HTTP |
|
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. |
| HESP - High Efficiency Streaming Protocol |
|
| draft-theo-hesp-06.txt |
| Date: |
17/04/2024 |
| Authors: |
Pieter-Jan Speelmans |
| Working Group: |
Individual Submissions (none) |
|
This document describes a protocol for delivering multimedia data, enabling ultra-low latency and fast channel change over HTTP networks. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 2 of this protocol. |
| Constraining RPKI Trust Anchors |
|
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| BGP Operations for Inter-domain SAV |
|
|
This document attempts to present deployment considerations of source address validation using BGP protocol in inter-domain network. |
| A Method for Exploring Latency Correlation in Multipath Networks |
|
|
The exploration of latency correlation patterns is of great significance for characterizing network states. However, existing measurement approaches have to confront multiple challenges in detecting latency correlation factors, such as probing speed, routing hops and geographical locations. In this paper, we conduct three tasks to handle these issues. The first is to construct relative latency measurement strategies for individual machines without any time synchronization and control plane requirements. The probing speed has been increased by 14.3% in the same hardware conditions. In 4G/5G heterogeneous edges enabled by different mobile operators, worldwide 5003 target servers are selected to acquire more than 1TB network datasets. The second is to reveal the potential modes between latency and routing hops. Surprisingly, 91.2% available targets present non-positive characteristics in extreme cases. The third is to analyze the fine-grained relationship between latency and geographical locations. We found that the significance of mean backward receiving delay is higher than other parameters, with a maximum of 33%. Finally, we also made optimizations regarding latency compression and time accuracy in multipath networks. The experimental data have been released to an open-source community for further investigations. |
| Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane |
|
| draft-ietf-spring-bfd-10.txt |
| Date: |
17/04/2024 |
| Authors: |
Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, Jiang Wenying |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path (LSP) Ping to bootstrap a BFD session, optional control of the selection of a segment list as the reverse direction of the BFD session, applicability of BFD Demand mode, and Seamless BFD in the SR-MPLS domain. Also, the document describes the use of the BFD Echo function with the BFD Control packet payload. |
| Compact TLS 1.3 |
|
| draft-ietf-tls-ctls-10.txt |
| Date: |
17/04/2024 |
| Authors: |
Eric Rescorla, Richard Barnes, Hannes Tschofenig, Benjamin Schwartz |
| Working Group: |
Transport Layer Security (tls) |
|
This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. |
|
|
| |
| Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security |
|
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations. |
| Data Transmission Security of Identity Resolution in Industrial Internet |
|
|
This draft presents a comprehensive overview of the data transmission security within the identity resolution system for the Industrial Internet. Identity resolution systems play a vital role in the Industrial Internet, facilitating secure sharing and intelligent correlation of heterogeneous information across various organizations. This draft focuses on the security services that identity resolution systems should provide during the resolution process. |
| Securing service-to-service traffic by WIMSE Token |
|
|
This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens. |
| Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects |
|
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. |
| YANG Data Model for Scheduled Attributes |
|
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
|
|
| |
| BGP Dissemination of L2 Flow Specification Rules |
|
|
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. |
| X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs |
|
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates |
| LISP YANG Model |
|
| draft-ietf-lisp-yang-21.txt |
| Date: |
15/04/2024 |
| Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| Binary Uniform Language Kit 1.0 |
|
|
This specification describes a uniform, decentrally extensible and efficient format for data serialization. |
| Just because it's an Internet-Draft doesn't mean anything... at all... |
|
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| SSH Agent Protocol |
|
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. |
| LISP Data-Plane Telemetry |
|
|
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. |
| Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX |
|
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. |
| Performance Measurement for Geneve |
|
|
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
| Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management |
|
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. |
| KEM-based Authentication for TLS 1.3 |
|
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| KEM-based pre-shared-key handshakes for TLS 1.3 |
|
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| Forward Error Correction (FEC) for SCHC framework |
|
|
This document describes a Forward Error Correction (FEC) method that is applied over the SCHC framework to improve the network performance under certain range of loss/error rates. |
| Double Nonce Derive Key AES-GCM (DNDK-GCM) |
|
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM) that operates with a 32- byte root key and encrypts with a 24-byte random nonce, and optionally provides for key commitment. Encryption takes the root key and a random nonce, derives a fresh encryption key and a key commitment value, invokes AES-GCM with the derived key and a 12-byte zero nonce, and outputs the ciphertext, authentication tag and the key commitment value. The low collision probability with 24-byte random nonces extends the lifetime of the root key and this supports processing up to 2^64 bytes under one root key. DNDK-GCM involves a small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption on AES as a pseudorandom permutation. |
| Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices |
|
|
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. |
|
|
| |
| Maintaining CCNx or NDN flow balance with highly variable data object sizes |
|
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| Security Technical Specification for Smart Devices of IoT |
|
|
With the development of IoT, the security of smart devices has become an important issue for us to discuss. This draft proposes a security framework and detailed requirements in terms of hardware, system, data, network, and management to ensure the security of IoT smart devices. Specifically, hardware security includes the security of hardware interfaces and components. System security encompasses firmware security, security audits, and more. Data security involves data verification and protection of sensitive data.Network security entails stream protection, session security, and more. |
| Technical Requirements for Secure Access and Management of IoT Smart Terminals |
|
|
It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. |
| Open Service Access Protocol for IoT Smart Devices |
|
|
With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. |
| Network Proactive Defense based on Source Address Validation |
|
|
Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. |
| Security Considerations for Tenant ID and Similar Fields |
|
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| Model and Test Methods for LTE-V2X Physical Layer Key Distribution System |
|
|
There are several key distribution systems based on the physical layer of the LTE Vehicle-to-Everything (V2X) communication system, utilizing the random and high-agreement secret key generation schemes from noisy wideband channels. These systems are used in conjunction with physical layer authentication systems that are also based on physical characteristics. To characterize these systems, this document proposes a reference model and several test methods of main technical parameters of such systems, including average key generation rate as well as the consistency and the randomness of generated key bits. |
| Classic McEliece |
|
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. |
| LTE-D Physical Layer Device Authentication Protocol |
|
|
This document describes a physical layer device authentication protocol based on the physical layer unclonable fingerpint (PUF) technique for LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle- to-Everything), to help the LTE-D message receiver confirm the identity of the LTE-D message sender. PUF utilizes intrinsic nonlinear characters of the transmission signal to identificate the devices and coresponding wireless signal transmitters, and is suitable for critical vehicular communication scenarios by its immunity against traditional cryptographic attacks. The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism. |
| Support of Network Observation Timestamping in YANG Notifications |
|
|
This document extends the YANG Notification header with the YANG objects observation timestamping, both for the "push-update" and "push-change-update" notifications. |
| Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
|
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, and Classic McEliece. |
| Allowing Experimental Error Codes in the Path Computation Element Protocol |
|
|
Experimental RFCs are often considered beneficial approaches to developing new protocol features. To that end, sub-ranges of code point registries are often designated as for experimental use. IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). According to RFC 5440 as updated by RFC 8356, the allocation policies for the registries for PCEP messages, objects, and TLV types are IETF Review with some sub-ranges of these registries being assigned for Experimental Use. However, the registry of PCEP Error-Types and Error-values has only the IETF Review assignment policy meaning that experimentation is somewhat limited. This document updates RFC 5440 by designating a range of PCEP Error- Types for Experimental Use. |
| The Network Geographic identification in Computing-Aware Traffic Steering |
|
| draft-ma-cats-ngid-01.txt |
| Date: |
14/04/2024 |
| Authors: |
Yuyin Ma, Tianhao Peng, Guoqing Dong, Qixuan Zhang, Xiaoshuang Lv, Guangjing He, Yiyun Zhang, Yuanming Sun, Qihao Si, Haocheng Lang, Xiuling Wang |
| Working Group: |
Individual Submissions (none) |
|
This document proposes a novel network address encoding scheme, called Network Geoidentifier (NGID), which aims to improve the efficiency and accuracy of network device management by directly embedding geolocation information (latitude and longitude) into IPv6 and IPv4 addresses. This approach provides a native support for the geolocation of network devices and is expected to have a significant impact on the future of network management and service positioning. |
|
|
| |
| RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
|
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| A YANG Data Model for Ethernet TE Topology |
|
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. |
| A YANG Data Model for Client-layer Tunnel |
|
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. |
| Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks |
|
|
Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds fine-grained network management to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF- based YANG and RESTful API capabilities. |
| Intra-domain Source Address Validation (SAVNET) Architecture |
|
|
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. |
|
|
| |
| A YANG Data Model for L1 Connectivity Service Model (L1CSM) |
|
| draft-ietf-ccamp-l1csm-yang-26.txt |
| Date: |
11/04/2024 |
| Authors: |
Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). |
| Secondary Certificate Authentication of HTTP Servers |
|
|
This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. |
| Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries |
|
|
This memo describes an architecture for trust registry membership association and verification using Decentralized Identifiers (DIDs), trust registries, and the DNS. This architecture provides a verifier with a simple process by which to determine and verify an issuer's membership in a trust registry. |
| TCP-AO Protection for BGP Monitoring Protocol (BMP) |
|
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in RFC5925, for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao. |
| Updates to RFC Publication Formats |
|
|
draft-rswg-rfc7990-updates, the successor to RFC 7990, defines the definitive version of an RFC as a published RFC with is in RFCXML. It defines publication versions of the RFC as published RFCs in the publication formats such as PDF, plain text, and HTML. draft-rswg- xml2rfcv3-implemented is updating the specification for the RFCXML format. This document updates some of the publication formats, specifically updating RFC 7992, RFC 7994, RFC 7995, and RFC 8153. Because RFC 7990 mentions some of the features of the publication formats, this document also updates RFC 7990. There is a repository for this draft at https://github.com/paulehoffman/pub-format-updates (https://github.com/paulehoffman/pub-format-updates). |
| RDAP Extension for DNS DELEG |
|
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. |
| Static Context Header Compression (SCHC) Architecture |
|
|
This document defines the SCHC architecture. |
|
|
| |
| Guidelines for Writing Cryptography Specifications |
|
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. |
| Updates to Lightweight OCSP Profile for High Volume Environments |
|
| draft-ietf-lamps-rfc5019bis-08.txt |
| Date: |
10/04/2024 |
| Authors: |
Tadahiko Ito, Clint Wilson, Corey Bonnell, Sean Turner |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1. |
| Updates to Anycast Property advertisement for OSPFv2 |
|
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| RESTCONF Extension to support Trace Context Headers |
|
|
This document extends the RESTCONF protocol in order to support trace context propagation as defined by the W3C. |
| INIT Forwarding for the Stream Control Transmission Protocol |
|
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. |
| Crowd Sourced Remote ID |
|
|
This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. |
| Methods for Remotely Measuring IP Spoofing Capability |
|
|
This document summarizes and standardizes methods for remotely measuring a network's IP spoofing capability. For outbound spoofing capability measurement, i.e., whether the network allows IP spoofing traffic to be sent from inside the network to the outside of the network, DNS traceroute can be used to check whether spoofed packets are generated in the network and sent to outside of the network. For inbound spoofing capability measurment, i.e., whether the network allows IP spoofing traffic from the outside the network to arrive inside, DNS resolver and ICMPv6 rate limiting mechanism can be utilized to check whether spoofed packets are received by devices in the network. |
| Privacy Pass Issuance Protocols with Public Metadata |
|
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
|
|
| |
| Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) |
|
| draft-ietf-core-oscore-edhoc-11.txt |
| Date: |
09/04/2024 |
| Authors: |
Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander |
| Working Group: |
Constrained RESTful Environments (core) |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. |
| PCEP Procedures and Extension for VLAN-based Traffic Forwarding |
|
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. |
| Trusted Domain SRv6 |
|
|
SRv6 as designed has evoked interest from various parties, though its deployment is being limited, amongst other things, by known security problems in its architecture. This document specifies a standard way to create a solution that closes some of the major security concerns, while retaining the tenants of the SRv6 protocol. |
| Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses |
|
| draft-sipcore-rfc7976bis-01.txt |
| Date: |
09/04/2024 |
| Authors: |
Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske |
| Working Group: |
Individual Submissions (none) |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
| Proof of Issuer Key Authority (PIKA) |
|
|
A relying party verifying a JSON Web Token (JWT) needs to verify that the public key used to verify the signature legitimately represents the issuer represented in the "iss" claim of the JWT. Today, relying parties commonly use the "iss" claim to fetch a set of authorized signing keys over HTTPS, relying on the security of HTTPS to establish the authority of the downloaded keys for that issuer. The ephemerality of this proof of authority makes it unsuitable for use cases where a JWT might need to be verified for some time. In this document, we define a format for Proofs of Issuer Key Authority, which establish the authority of a key using a signed object instead of an HTTPS connection. |
| SRv6 Resource Programming with NRP flavor |
|
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes |
|
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with attributes signaling validation state may flood needless BGP UPDATE messages through the global Internet routing system, when, for example, Route Origin Authorizations are issued, revoked, or RPKI-To- Router sessions are terminated. Operators SHOULD ensure Validation States are not signalled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into distinct BGP Communities. |
|
|
| |
| RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
|
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| Crowd Sourced Remote ID |
|
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| Revised Cookie Processing in the IKEv2 Protocol |
|
|
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. |
| A Blockchain Trusted Protocol for Intelligent Communication Network |
|
|
This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. |
| Bundle Protocol Endpoint ID Patterns |
|
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and CBOR encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its CBOR form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| Computing-aware Traffic Steering for attack detection |
|
|
This document describes the closed-loop framework for computing-aware traffic steering for attack detection (CATS-AD). The computing-aware traffic steering is determined by composing selected service instances and overlay links. The service instances are selected according to the computing power of service instances. This document describes the closed-loop framework for attacks detection and how to select and combine service instances to form a computing-aware service function chain (SFC). |
| EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6 Underlay |
|
| draft-xie-v6ops-evn6-01.txt |
| Date: |
08/04/2024 |
| Authors: |
Chongfeng Xie, Xing Li, Congxiao Bao, Mark Smith, Jibin Sun |
| Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| PCEP Extensions for Signaling Multipath Information |
|
| draft-ietf-pce-multipath-11.txt |
| Date: |
08/04/2024 |
| Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra |
| Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new PCEP mechanisms are meant to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. |
| Group Address Allocation Protocol (GAAP) |
|
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. |
| Batched Token Issuance Protocol |
|
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to isse more than one token at a time. |
|
|
| |
| BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover |
|
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. |
| Integrity of In-situ OAM Data Fields |
|
|
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path in the network. IETF protocols require features to ensure their security. This document describes the integrity protection of IOAM-Data-Fields. |
| ICANN Registrar Interfaces |
|
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
|
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. |
| Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
|
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| Terminal-based joint selection and configuration of MEC host and RAW network |
|
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| Extensions to enable wireless reliability and availability in multi-access edge deployments |
|
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| MIPv6 RAW mobility |
|
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| Discovery of Network Rate-Limit Policies (NRLPs) |
|
|
Traffic exchanged over a network attachment may be subject to rate- limit policies. These policies may be intentional policies (e.g., enforced as part of the activation of the network attachment and typically agreed upon service subscription) or be reactive policies (e.g., enforced temporarily to manage an overload or during a DDoS attack mitigation). Networks already support mechanisms to advertize a set of network properties to hosts using Neighbor Discovery options. Examples of such properties are link MTU (RFC 4861) and PREFIX64 (RFC 8781). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate these policies to hosts. For address family parity, a new DHCP option is also defined. |
|
|
| |
| Dynamic Flooding on Dense Graphs |
|
|
Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. |
| Optimizations of PCEP Link-State(LS) Synchronization Procedures |
|
|
For a Path Computation Element (PCE) to perform its computations, it is important that Link-State (and TE) information be complete and accurate each time. This requires a reliable Link-State Synchronization mechanism between the PCE and path computation clients (PCCs), and between cooperating PCEs. The basic mechanism for Link-State Synchronization is part of the PCEP Link-State (and TE) draft. This draft presents motivations for optimizations to the base PCEP Link-State (and TE) procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. |
| MIMI Metadata Minimalization (MIMIMI) |
|
|
This document describes a proposal to run the MIMI protocol in a way that reduces the ability of the Hub and service providers to associate messaging activity of clients with their respective identities. For now, this document only contains a high-level description of the mechanisms involved. |
| Secure Asset Transfer Protocol (SATP) Core |
|
| draft-ietf-satp-core-04.txt |
| Date: |
05/04/2024 |
| Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior |
| Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| Detecting RRDP Session Desynchronization |
|
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. |
| Hybrid key exchange in TLS 1.3 |
|
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. |
| Best Current Practice for Workload Identity |
|
|
The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and client_secret, can be complex and error-prone. "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads. This document specifies the use of JWTs for client credentials in container orchestration systems to improve interoperability in orchestration systems, to reduce complexity for developers, and motivates authorization server to support RFC 7523. |
|
|
| |
| WebP Image Format |
|
| draft-zern-webp-15.txt |
| Date: |
04/04/2024 |
| Authors: |
James Zern, Pascal Massimino, Jyrki Alakuijala |
| Working Group: |
Applications and Real-Time Area (art) |
|
This document defines the WebP image format and registers a media type supporting its use. |
| JMAP for Sieve Scripts |
|
|
This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. |
| YANG Groupings for TCP Clients and TCP Servers |
|
|
This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. |
| Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
|
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
|
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
|
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
|
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
|
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
|
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| Multiple IPv4 - IPv6 address mapping translator (M46T) |
|
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E) |
|
|
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. |
| Multi-Stage Transparent Server Load Balancing |
|
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
|
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| ESP Echo Protocol |
|
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| Gender Representation in the IETF Nominating Committees |
|
|
This document extends the existing limit on nomcom representation by company in order to improve gender diversity by ensuring that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. |
| Registry policies "... with Expert Review" |
|
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. |
| Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing |
|
|
Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element(PCE). Since SR can be applied to both MPLS and IPv6 data-planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data- planes. The Path Computation Element communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data-plane within PCEP. |
| Secure Frame (SFrame) |
|
| draft-ietf-sframe-enc-09.txt |
| Date: |
04/04/2024 |
| Authors: |
Emad Omara, Justin Uberti, Sergio Murillo, Richard Barnes, Youenn Fablet |
| Working Group: |
Secure Media Frames (sframe) |
|
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (selective forwarding units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. |
|
|
| |
| A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services |
|
|
This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types of network resources. |
| An Architecture for More Instant Messaging Interoperability (MIMI) |
|
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. |
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
|
| draft-ietf-mimi-protocol-00.txt |
| Date: |
02/04/2024 |
| Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| OSPF Abnormal State Information |
|
|
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. |
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path |
|
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. |
| Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path |
|
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. |
| A Forward-Search P2P TE LSP Inter-Domain Path Computation |
|
|
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| A Forward-Search P2MP TE LSP Inter-Domain Path Computation |
|
|
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks. |
|
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. |
| Extensions to PCEP for Distributing Label Cross Domains |
|
|
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). |
| BGP Extensions for IDs Allocation |
|
|
This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed. |
| BGP-SPF Flooding Reduction |
|
|
This document describes extensions to Border Gateway Protocol (BGP) for flooding the link states on a topology that is a subgraph of the complete topology of a BGP-SPF domain, so that the amount of flooding traffic in the domain is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. |
| IGP Extensions for Advertising Node Index |
|
| draft-chen-lsr-adv-ni-04.txt |
| Date: |
02/04/2024 |
| Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. |
| SR-MPLS FRR Extension |
|
|
The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node on an SR-MPLS path by the neighbor upstream node as point of local repair (PLR) of the failed node. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbor upstream node of the failed node will no longer have a route to the failed node. This document describes a simple mechanism to extend the fast re-route protection for the failure on an SR-MPLS path after the IGP converges. The mechanism protects the node SID, adjacency SID and binding SID of the failed node on the path. |
| External Keys For Use In Internet X.509 Certificates |
|
|
Many of the post quantum cryptographic algorithms have large public keys. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and algorithms for referencing external public key data by hash, and location, for example URL. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. |
| Proposal for the Introduction of Email Headers for Phishing Detection Training |
|
|
This document proposes the addition of new email headers designed specifically to identify emails that are sent as part of phishing detection training programs. These headers would allow recipients to verify the authenticity of training emails using DNS queries to confirm that the sending domains are authorized to send these types of emails. |
| DataRight+: Admission Control Baseline |
|
|
The establishment of a shared model of trust is critical to any functioning technology ecosystem, particularly when it relates to the sharing of data and the execution of Consumer specific actions. Traditional models of trust have typically revolved around implicit trust established through bi-lateral arrangements (i.e. legal contracts) between participants. The issue with this approach is that, at scale, it is not possible for all participants to efficiently establish communication with all other participants. This leads to the requirement for a mechanism to establish trust across participants in a way that the business layer of an organisation has confidence in ensuring participant interaction is validated. |
| DataRight+: Australian CDR Profile |
|
|
This is the ecosystem profile for the Australian CDR describing the composite components to form the technical infrastructure operating to form the Australian Consumer Data Right. This specification is intended to result in a [CDS] compatible implementation. Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| YANG Model for the NETCONF default attribute |
|
|
This document defines a YANG module with the "default" attribute using the namespace and prefix defined in [RFC6243]. This enables usage of the "default" attribute in e.g. YANG JSON encoding. |
| EAT Media Types |
|
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). |
|
|
| |
| Usage Limits on AEAD Algorithms |
|
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| Key Blinding for Signature Schemes |
|
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| The Link-Template HTTP Header Field |
|
|
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. |
| The FNV Non-Cryptographic Hash Algorithm |
|
| draft-eastlake-fnv-22.txt |
| Date: |
01/04/2024 |
| Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that is referenced in a number of standards documents and widely used. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. |
| IPv6 is Classless |
|
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| Information Awareness System for Computing-Aware Service Function Chain (IAS-CASFC): Security Service Aspect |
|
|
This document describes the Information Awareness System of the Computing-Aware Service Function Chain (ISA-CASFC) from the security service aspect, including the system architecture, network, and computing information details. The SFC enables traffic to pass through the ordered Network Security Function (NSF) path, enabling end-to-end security services. Differences in the available network and computing resources cause performance differences between NSF instances deployed on different service sites. It can be seen that the routing decision on NSF instances will affect the quality of the security service. Therefore, it is necessary to implement the CA-SFC to ensure the quality of security service. This document extends the CATS framework and the CATS Computing and Network Information Awareness (CNIA) architecture for CA-SFC, and describes the network and computing information content for security service. |
| DataRight+: Energy Resource Set |
|
|
This is the resource set profile outlining the energy sector related endpoints. In addition to outlining Initiator and Provider provisions it also specifies requirements for the Energy Authority (electricity assets and usage) and Energy Plan Website (retail electricity plan information). Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+: Common Resource Set |
|
|
This is the resource set profile outlining the common endpoints utilised across multiple industries. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+: Banking Resource Set |
|
|
This is the resource set profile outlining the banking sector related endpoints. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+ Security Profile: Baseline |
|
|
The DataRight+ Security Profile: Baseline is intended to be a compatible profile of the [CDS] presented as a profile of [FAPI-1.0-Advanced]. This profile focuses primarily on the obligations between Provider and Initiator with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of specified authorisation types. This profile does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the [CDS]. Further terminology used is deliberately jurisdiction agnostic, please refer to [DATARIGHTPLUS-ROSETTA] for specific ecosystem mappings. |
| DataRight+: Sharing Arrangement V1 |
|
|
This specification outlines the technical requirements related to the delivery of Sharing Arrangement V1. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| IGMP and MLD Snooping Yang Module Extension for L2VPN |
|
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. |
| Rate-Limited Token Issuance Protocol |
|
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. |
| The PrivateToken HTTP Authentication Scheme Extensions Parameter |
|
|
This document specifies a new parameter for the "PrivateToken" HTTP authentication scheme. This purpose of this parameter is to carry extensions for Privacy Pass protocols that support public metadata. |
| Return Routability Check for DTLS 1.2 and DTLS 1.3 |
|
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. |