|
|
| |
| 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. |
| IAB Barriers to Internet Access of Services (BIAS) Workshop Report |
|
|
The “Barriers for Internet Access of Services (Bias)” workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered three areas of interest: the role of community networks in Internet Access of Services; reports and comments on the observed digital divide; and measurements of censorship and censorship circumvention. This report summarizes the workshop's discussion and serves as a reference for reports on the current barriers to Internet Access. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report were expressed during the workshop by participants and do not necessarily reflect IAB's views and positions. |
| 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. |
| Performance Measurement with Asymmetrical Packets in STAMP |
|
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| 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. |
| Flexible Algorithms: Bandwidth,Delay,Metrics and Constraints |
|
|
Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. |
| 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. |
| BPF Instruction Set Architecture (ISA) |
|
|
This document specifies the BPF instruction set architecture (ISA). |
| Additional Parameter sets for HSS/LMS Hash-Based Signatures |
|
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| 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. |
| A Formalization of Symbolic Expressions |
|
|
The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. |
| 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. |
| Distribute SRv6 Locator by DHCP |
|
|
In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned a locator, and segment IDs are generated within the address space of this locator. This document describes a method for assigning locators to SRv6 Segment Endpoint Nodes through DHCPv6. |
| 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. |
|
|
| |
| A Common YANG Data Model for Scheduling |
|
|
This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings. |
| Passive DNS - Common Output Format |
|
|
This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily. |
| Unicode Character Repertoire Subsets |
|
|
This document discusses specifying subsets of the Unicode character repertoire for use in protocols and data formats. It also specifies those subsets in as PRECIS profiles. |
| Unmasked BIER Mode |
|
|
The document introduces a new mode of interpretation of the bitmask field in the BIER encoding, called unmasked BIER, that solves the problem of BIER originator targeting receivers across many different sets and hence, in worst case, degrading into ingress replication. |
| Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group |
|
|
RFC8110 describes Opportunistic Wireless Encryption (OWE), a mode that allows unauthenticated clients to connect to a network using encrypted traffic. This document transfers the ongoing maintenance and further development of the protocol to the IEEE 802.11 Working Group. This documents updates RFC8110 by noting that future work on the protocol described in RFC8110 will occur in the IEEE 802.11 Working Group. |
| Ownership and licensing statements in YANG |
|
| draft-ietf-opsawg-ol-06.txt |
| Date: |
27/04/2024 |
| Authors: |
Eliot Lear, Carsten Bormann |
| Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
|
|
| |
| DNS Resolver Information |
|
|
This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such an information is beyond the scope of this document. |
| 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. |
| ACLs within the NFSv4 Protocols |
|
|
This document describes the structure of NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality is covered as well. While the goals of the description are similar to that used in previous specifications, the approach taken is substantally different, in that the relationship of the multiple ACL models supported has changed. A core set of functionality, derived form the the now-withdrawn POSIX draft ACLs is presented as the conceptual base of the feature set. Additional features used to provide the functionality within the NFSv4 ACL model are presented as OPTIONAL extensions to that core. The current version of the document is intended, in large part, to result in working group discussion regarding repairing problems with previous specifications of ACL-related features and to enable work to provide a greater degree of interoperability than has been available heretofore. The drafts a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| Flow Metadata for Collaborative Host/Network Signaling |
|
|
This document defines per-flow and per-packet metadata for both network-to-host and host-to-network signaling in Concise Data Definition Language (CDDL) which expresses both CBOR and JSON. The common metadata definition allows interworking between signaling protocols with high fidelity. The metadata is also self- describing to improve interpretation by network elements and endpoints while reducing the need for version negotiation. |
| An Update on Milestones |
|
|
As mandated in RFC 2418, working group charters currently contain milestones. However, these milestones are often sufficiently out of date that they no longer provide value. This document exists to facilitate a community discussion around the future of milestones. This document could potentially update RFC 2418. |
| 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-LS Extension for Inter-AS Topology Retrieval |
|
|
This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. |
| BGP Extension for 5G Edge Service Metadata |
|
|
This draft describes a new Metadata Path Attribute and some Sub-TLVs for egress routers to advertise the Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE). |
| 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. |
| An Architecture for DNS-Bound Client and Sender Identities |
|
| draft-ietf-dance-architecture-05.txt |
| Date: |
24/04/2024 |
| Authors: |
Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson |
| Working Group: |
DANE Authentication for Network Clients Everywhere (dance) |
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. |
| 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. |
| A Profile for Mapping Origin Authorizations (MOAs) |
|
|
For the authenticity of the mapping origin of IPv4 address block in IPv6-only networks, this document defines a standard profile for Mapping Origin Authorizations (MOAs). MOA is a cryptographically signed object that provides a means of verifying that the holder of a set of IPv4 prefixes has authorized an IPv6 mapping prefix to originate mapping for those prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. |
| 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. |
|
|
| |
| More Instant Messaging Interoperability (MIMI) message content |
|
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. |
| Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type |
|
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server of changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server. |
| Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks |
|
|
Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. |
| BGP Extension for Distributing CP Threshold Constraints of SR Policy |
|
|
This document defines the extension of BGP to distribute threshold and metric constraint parameters of candidate paths for SR Policy to achieve flexible path selection. |
| EAT profile for Intel® Trust Domain Extensions (TDX) attestation result |
|
|
Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment. |
| A Mechanism for X.509 Certificate Discovery |
|
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether or not to fetch the secondary certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of primary certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. It does not focus on identity assurance between the primary and secondary certificates, deferring such considerations to complementary mechanisms. |
| Extending ICMP for Node Identification |
|
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where each interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). |
| BGP Link State Extensions for Scalable Network Resource Partition |
|
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. |
| Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values |
|
|
RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a registry for "IS-IS Neighbor Link-Attribute Bit Values". This document changes the registration procedure for that registry from "Standards Action" to "Expert Review". |
| 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. |
| Requirements for Solutions that Support MPLS Network Actions (MNA) |
|
|
This document specifies requirements for the development of MPLS Network Actions (MNA) which affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router - LER). |
| Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifier with MPLS Data Planes |
|
|
Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. Path Segment can be used in an SR over MPLS (SR-MPLS) data plane. This document provides Target Forwarding Equivalence Class (FEC) Stack TLV and sub-TLV definitions for PSID. |
| Network File System (NFS) Version 4 Minor Version 1 Protocol |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| Explicit Congestion Notification for the Stream Control Transmission Protocol |
|
|
This document describes the addition of the Explicit Congestion Notification (ECN) to the Stream Control Transmission Protocol (SCTP). |
| SRv6 Egress Protection in Multi-homed scenario |
|
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
|
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| Basic Support for IPv6 Networks Operating over 5G Vehicle-to-Everything Communications |
|
|
This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to the existing IPv6 protocol stack. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 in more complex 5G scenarios are not covered in this specification and are a subject for future work. |
| Intent-Based Network Management Automation in 5G Networks |
|
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| BGP SPF Extensions for Intra-domain SAVNET |
|
|
This document describes the BGP SPF protocol extension that is required for Source Address Validation in Intra-domain. By extending BGP SPF and adding the BGP SPF protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification. |
| Service Interworking between SRv6 |
|
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
|
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
|
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| Multicast Listener Discovery Version 2 (MLDv2) for IPv6 |
|
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. |
| Internet Group Management Protocol,Version 3 |
|
|
This document specifies a revised Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 3376. |
| Convergence of Congestion Control from Retained State |
|
| draft-ietf-tsvwg-careful-resume-08.txt |
| Date: |
22/04/2024 |
| Authors: |
Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections. It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are stored, allowing them to be later used to modify the congestion control behavior of a subsequent connection. It describes assumptions and defines requirements for how a sender utilizes these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilize available capacity. It discusses how use of the method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |
|
|
| |
| IPv6 Query for Enabled In-situ OAM Capabilities |
|
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Ping Enabled IOAM Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| Delay-based Metric Extension for the Babel Routing Protocol |
|
|
This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower latency links over higher latency ones. |
| Constrained Resource Identifiers |
|
| draft-ietf-core-href-15.txt |
| Date: |
21/04/2024 |
| Authors: |
Carsten Bormann, Henk Birkholz |
| Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –15 of this draft continues -14 by picking up // more comments, such as moving to a CRI scheme number registration // system based on unsigned numbers. This revision still contains // open issues and is intended to serve as a snapshot. |
| Structured Field Values for HTTP |
|
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document obsoletes RFC 8941. |
| LISP Map Server Reliable Transport |
|
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. |
| Generic Multicast Router Election on LAN's |
|
|
When a host is connected to multiple multicast capable routers, each of these routers is a candidate to process the multicast flow for that LAN, but only one router should be elected to process it. This document proposes a generic multicast router election mechanism using Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) that can be used by any Multicast Overlay Signalling Protocol (MOSP). Having such generic election mechanism removes a dependency on Protocol Independent Multicast (PIM). |
| Security for the NFSv4 Protocols |
|
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the ACL feature, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881, |
| A Collaborative Framework for Cyberspace Governance: the Internet of Governance |
|
|
This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples. |
| EAT Attestation Results |
|
| draft-fv-rats-ear-03.txt |
| Date: |
21/04/2024 |
| Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov |
| Working Group: |
Individual Submissions (none) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| Integration of Speech Codec Enhancement Methods into the Opus Codec |
|
|
This document proposes a method for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| Resource Guarantee for SRv6 Policies |
|
|
This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list , the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. |
| An Application Layer Interface for Non-IP device control (NIPC) |
|
| draft-brinckman-nipc-01.txt |
| Date: |
21/04/2024 |
| Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| Working Group: |
Individual Submissions (none) |
|
This memo specifies RESTful application layer interface for gateways providing operations against non-IP devices. The described interface is extensible. This memo initially describes Bluetooth Low Energy and Zigbee as they are the most commonly deployed. |
| IGP Color-Aware Routing |
|
| draft-lin-lsr-igp-car-01.txt |
| Date: |
21/04/2024 |
| Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| Static Context Header Compression and Fragmentation for Zero Energy Devices |
|
|
This document describes the use of SCHC for very constraint devices. The use of SCHC will bring connectivity to devices with restrained use of battery and long delays. |
| OAuth 2.0 Attestation-Based Client Authentication |
|
|
This specification defines a new method of client authentication for OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme. |
| Private Line Emulation over Packet Switched Networks |
|
| draft-ietf-pals-ple-04.txt |
| Date: |
21/04/2024 |
| Authors: |
Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Chris Brown |
| Working Group: |
Pseudowire And LDP-enabled Services (pals) |
|
This document describes a method for encapsulating high-speed bit- streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency. |
|
|
| |
| Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
|
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. |
| A YANG Data Model for Optical Transport Network Topology |
|
| draft-ietf-ccamp-otn-topo-yang-18.txt |
| Date: |
19/04/2024 |
| Authors: |
Haomian Zheng, Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. This model enables clients, which interact with a transport domain controller, for OTN topology-related operations such as obtaining the relevant topology resource information. |
| Constrained Application Protocol (CoAP) Performance Measurement Option |
|
| draft-ietf-core-coap-pm-02.txt |
| Date: |
19/04/2024 |
| Authors: |
Giuseppe Fioccola, Tianran Zhou, Massimo Nilo, Fabrizio Milan, Fabio Bulgarella |
| Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. |
| BGP SR Policy Extensions to Enable IFIT |
|
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. |
| 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. |
| OAuth Status Attestations |
|
|
Status Attestation is a signed object that demonstrates the validity status of a digital credential. These attestations are periodically provided to holders, who can present these to Verifiers along with the corresponding digital credentials. The approach outlined in this document makes the verifiers able to check the non-revocation of a digital credential without requiring to query any third-party entities. |
| OAM for use in GENEVE |
|
| draft-ietf-nvo3-geneve-oam-10.txt |
| Date: |
19/04/2024 |
| Authors: |
Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti |
| Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. |
| An RDAP Extension for Geofeed Data |
|
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and link relation type for the associated link objects included in responses. |
| RPKI Manifest Number Handling |
|
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases |
|
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". |
| New Protocols Must Require TLS 1.3 |
|
|
TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Since TLS 1.3 use is widespread, new protocols must require and assume its existence. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |
|
|
| |
| Discovery for BRSKI variations |
|
|
This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators. |
| Task Extensions to iCalendar |
|
|
This document updates and defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. |
| CDNI Capacity Capability Advertisement Extensions |
|
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document supplements the CDNI Capability Objects defined in RFC 8008. |
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) |
|
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. |
| 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. |
| Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
|
|
This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. |
| ISP Dual Queue Networking Deployment Recommendations |
|
|
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment decisions are ultimately left to implementers. This document explores the potential implications of key deployment decisions and makes recommendations for those decisions that may help drive adoption. |
| MNA for Performance Measurement with Alternate Marking Method |
|
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| Enforcing end-to-end delay bounds via queue resizing |
|
|
This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. |
| Ethernet VPN Signalling Extensions for Bit-stream VPWS |
|
|
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN). |
| LDP Extensions to Support Private Line Emulation (PLE) |
|
|
This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks. |
| Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers |
|
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. |
| Security Considerations for Computing-Aware Traffic Steering |
|
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing node as well as workflows of CATS procedures. This document describes various threats and security concerns related to CATS networks and existing approaches to solve these threats. |
| Representing metadata annotations in YANG-CBOR |
|
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| (Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS |
|
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| The "xml2rfc" version 3 Vocabulary as Implemented |
|
|
This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home pags at . Source code and issues list for this draft can be found at . |
| Detailed Software Supply Chain Uses Cases for SCITT |
|
| draft-ietf-scitt-software-use-cases-03.txt |
| Date: |
18/04/2024 |
| Authors: |
Henk Birkholz, Yogesh Deshpande, Dick Brooks, Bob Martin, Brian Knight |
| Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document includes a collection of representative Software Supply Chain Use Cases. These use cases aim to identify software supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. |
| Circuit Style Segment Routing Policies |
|
| draft-ietf-spring-cs-sr-policy-02.txt |
| Date: |
18/04/2024 |
| Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). |
| Workload Identity in a Multi System Environment (WIMSE) Architecture |
|
| draft-ietf-wimse-arch-00.txt |
| Date: |
18/04/2024 |
| Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |
|
|
| |
| JMAP Sharing |
|
|
This document specifies a data model for sharing data between users using JMAP. Future documents can reference this document when defining data types to support a consistent model of sharing. |
| Proxying Ethernet in HTTP |
|
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. |
| HESP - High Efficiency Streaming Protocol |
|
| draft-theo-hesp-06.txt |
| Date: |
17/04/2024 |
| Authors: |
Pieter-Jan Speelmans |
| Working Group: |
Individual Submissions (none) |
|
This document describes a protocol for delivering multimedia data, enabling ultra-low latency and fast channel change over HTTP networks. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 2 of this protocol. |
| Interconnecting domains with IBGP |
|
|
This document relaxes the recommendations specified in [RFC4364] and [RFC4456] allowing the building of Inter-domain L3VPN architecture with internal BGP. |
| Constraining RPKI Trust Anchors |
|
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to publicly-trusted Trust Anchors (TAs), as implemented in OpenBSD's rpki-client validator. The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. |
| BGP Operations for Inter-domain SAV |
|
|
This document attempts to present deployment considerations of source address validation using BGP protocol in inter-domain network. |
| 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. |
| Automatic Extended Route Optimization (AERO) |
|
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| Securing service-to-service traffic by WIMSE Token |
|
|
This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens. |
| Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects |
|
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. |
| On the use of the CMS signing-time attribute in RPKI Signed Objects |
|
|
In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. Signed Objects contain a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols. This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute. |
| YANG Data Model for Scheduled Attributes |
|
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
|
|
| |
| BGP Dissemination of L2 Flow Specification Rules |
|
|
This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined. |
| X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs |
|
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines Instant Messaging (IM) identity KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates |
| LISP YANG Model |
|
| draft-ietf-lisp-yang-21.txt |
| Date: |
15/04/2024 |
| Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| Binary Uniform Language Kit 1.0 |
|
|
This specification describes a uniform, decentrally extensible and efficient format for data serialization. |
| Just because it's an Internet-Draft doesn't mean anything... at all... |
|
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. |
| SSH Agent Protocol |
|
|
This document describes a key agent protocol for use in the Secure Shell (SSH) protocol. |
| LISP Data-Plane Telemetry |
|
|
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. |
| Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX |
|
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. |
| Performance Measurement for Geneve |
|
|
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
| Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management |
|
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. |
| KEM-based Authentication for TLS 1.3 |
|
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| KEM-based pre-shared-key handshakes for TLS 1.3 |
|
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
|
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| Forward Error Correction (FEC) for SCHC framework |
|
|
This document describes a Forward Error Correction (FEC) method that is applied over the SCHC framework to improve the network performance under certain range of loss/error rates. |
| A File Format to Aid in Consumer Privacy Enforcement,Research,and Tools |
|
| draft-colwell-privacy-txt-00.txt |
| Date: |
15/04/2024 |
| Authors: |
Nick Sullivan, Louise Van der Peet, Georgios Smaragdakis, Brien Colwell |
| Working Group: |
Individual Submissions (none) |
|
This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txt // https://datatracker.ietf.org/doc/html/rfc9309, security.txt // https://datatracker.ietf.org/doc/html/rfc9116, or ads.txt // https://iabtechlab.com/ads-txt/, in the / directory or /.well- known directory. The file format adds structured data for three areas: 1. A machine parsable and complete privacy policy 2. Consumer actions under their privacy rights 3. Cookie disclosures |
| Double Nonce Derive Key AES-GCM (DNDK-GCM) |
|
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM) that operates with a 32- byte root key and encrypts with a 24-byte random nonce, and optionally provides for key commitment. Encryption takes the root key and a random nonce, derives a fresh encryption key and a key commitment value, invokes AES-GCM with the derived key and a 12-byte zero nonce, and outputs the ciphertext, authentication tag and the key commitment value. The low collision probability with 24-byte random nonces extends the lifetime of the root key and this supports processing up to 2^64 bytes under one root key. DNDK-GCM involves a small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption on AES as a pseudorandom permutation. |
| Dynamic Networks to Hybrid Cloud DCs: Problems and Mitigation Practices |
|
|
This document describes a set of network-related problems enterprises face at the time of writing this document (2023) when interconnecting their branch offices with dynamic workloads in third-party data centers (DCs) (a.k.a. Cloud DCs). These problems are mainly from enterprises with conventional VPN services that want to leverage those networks (instead of altogether abandoning them). This document also describes various mitigation practices and actions to soften the issues induced by these problems. |
|
|
| |
| Support of Versioning in YANG Notifications Subscription |
|
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. |
| Maintaining CCNx or NDN flow balance with highly variable data object sizes |
|
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. |
| Security Technical Specification for Smart Devices of IoT |
|
|
With the development of IoT, the security of smart devices has become an important issue for us to discuss. This draft proposes a security framework and detailed requirements in terms of hardware, system, data, network, and management to ensure the security of IoT smart devices. Specifically, hardware security includes the security of hardware interfaces and components. System security encompasses firmware security, security audits, and more. Data security involves data verification and protection of sensitive data.Network security entails stream protection, session security, and more. |
| Technical Requirements for Secure Access and Management of IoT Smart Terminals |
|
|
It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process. |
| Open Service Access Protocol for IoT Smart Devices |
|
|
With the development of IoT (Internet of Things) technology, everything becomes interconnected. Mass IoT data, devices, businesses, and services adopt different data descriptions and service access methods, resulting in fragmentation issues such as data heterogeneity, device heterogeneity, and application heterogeneity. These issues hinder the development of the industry. To solve this problem, this draft proposes the requirements for IoT smart devices to transmit and control, as well as transmission and protocol interfaces. It is intended for program design, system testing and acceptance, and related research. The structured, unified, and standardized open service interconnection model reduces business replication costs and eliminates service barriers, thus promoting industrial development. |
| Network Proactive Defense based on Source Address Validation |
|
|
Source address validation (SAV) helps routers check the validity of packets. Networks can use the SAV capability to enhance threat awareness. This document proposes proactive defense network where routers can directly identify threats through SAV. The proactive threat awareness feature is helpful for satisfying the threat awareness requirement of ISPs. |
| Security Considerations for Tenant ID and Similar Fields |
|
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. |
| Model and Test Methods for LTE-V2X Physical Layer Key Distribution System |
|
|
There are several key distribution systems based on the physical layer of the LTE Vehicle-to-Everything (V2X) communication system, utilizing the random and high-agreement secret key generation schemes from noisy wideband channels. These systems are used in conjunction with physical layer authentication systems that are also based on physical characteristics. To characterize these systems, this document proposes a reference model and several test methods of main technical parameters of such systems, including average key generation rate as well as the consistency and the randomness of generated key bits. |
| Classic McEliece |
|
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. |
| LTE-D Physical Layer Device Authentication Protocol |
|
|
This document describes a physical layer device authentication protocol based on the physical layer unclonable fingerpint (PUF) technique for LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle- to-Everything), to help the LTE-D message receiver confirm the identity of the LTE-D message sender. PUF utilizes intrinsic nonlinear characters of the transmission signal to identificate the devices and coresponding wireless signal transmitters, and is suitable for critical vehicular communication scenarios by its immunity against traditional cryptographic attacks. The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism. |
| Support of Network Observation Timestamping in YANG Notifications |
|
|
This document extends the YANG Notification header with the YANG objects observation timestamping, both for the "push-update" and "push-change-update" notifications. |
| Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms |
|
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, and Classic McEliece. |
| Allowing Experimental Error Codes in the Path Computation Element Protocol |
|
|
Experimental RFCs are often considered beneficial approaches to developing new protocol features. To that end, sub-ranges of code point registries are often designated as for experimental use. IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). According to RFC 5440 as updated by RFC 8356, the allocation policies for the registries for PCEP messages, objects, and TLV types are IETF Review with some sub-ranges of these registries being assigned for Experimental Use. However, the registry of PCEP Error-Types and Error-values has only the IETF Review assignment policy meaning that experimentation is somewhat limited. This document updates RFC 5440 by designating a range of PCEP Error- Types for Experimental Use. |
| The Network Geographic identification in Computing-Aware Traffic Steering |
|
| draft-ma-cats-ngid-01.txt |
| Date: |
14/04/2024 |
| Authors: |
Yuyin Ma, Tianhao Peng, Guoqing Dong, Qixuan Zhang, Xiaoshuang Lv, Guangjing He, Yiyun Zhang, Yuanming Sun, Qihao Si, Haocheng Lang, Xiuling Wang |
| Working Group: |
Individual Submissions (none) |
|
This document proposes a novel network address encoding scheme, called Network Geoidentifier (NGID), which aims to improve the efficiency and accuracy of network device management by directly embedding geolocation information (latitude and longitude) into IPv6 and IPv4 addresses. This approach provides a native support for the geolocation of network devices and is expected to have a significant impact on the future of network management and service positioning. |
| SCIM Profile for Security Event Tokens |
|
| draft-ietf-scim-events-05.txt |
| Date: |
14/04/2024 |
| Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. |
|
|
| |
| RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
|
|
A visual volumetric video-based coding (V3C) [ISO.IEC.23090-5] bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant Internet Standards for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers |
|
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution limiting the port number ranges and using two test phases (phase 1 and phase 2). It is shown how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity. |
| A YANG Data Model for Ethernet TE Topology |
|
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. |
| 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. |
| IPv4 Parcels and Advanced Jumbos (AJs) |
|
|
IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs and a new link model for Internetworking. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4. |
| IPv6 Parcels and Advanced Jumbos (AJs) |
|
|
IPv6 packets contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as segments which the network layer packages into individual IPv6 packets each containing only a single segment. This specification presents new packet constructs termed IPv6 Parcels and Advanced Jumbos (AJs) with different properties. Parcels permit a single packet to include multiple segments as a "packet-of- packets", while AJs offer significant operational advantages over basic jumbograms for transporting singleton segments of all sizes ranging from very small to very large. Parcels and AJs provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) according to both the classic Internetworking link model and a new Delay Tolerant Network (DTN) link model. |
| IPv6 Extended Fragment Header for IPv4 |
|
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. |
| Intra-domain Source Address Validation (SAVNET) Architecture |
|
|
This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. |
|
|
| |
| EVPN Interworking with IPVPN |
|
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection in [RFC4271], but only for IPVPN and EVPN families. |
| A YANG Data Model for L1 Connectivity Service Model (L1CSM) |
|
| draft-ietf-ccamp-l1csm-yang-26.txt |
| Date: |
11/04/2024 |
| Authors: |
Young Lee, Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). |
| 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. |
| JMAP for Calendars |
|
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. |
| 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. |
| Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) |
|
|
This document describes a Same-origin policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients. The same- origin policy concept is a security mechanism to restrict how a document loaded from one origin can cause interaction with resources from another origin. Application of a same-origin policy in RRDP client/server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. This document updates RFC 8182. |
| A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits |
|
|
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network ((i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM))) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to ACs that are created using the Attachment Circuit (AC) service ("ietf-ac- svc") and network ("ietf-ac-ntw") models. |
| 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. |
| dCBOR: A Deterministic CBOR Application Profile |
|
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The CBOR Common Deterministic Encoding (CDE) Internet Draft builds on this by specifying a baseline for application profiles that wish to implement deterministic encoding with CBOR. The present document provides an application profile "dCBOR" that can be used to help achieve interoperable deterministic encoding based on CDE for a variety of applications wishing an even narrower and clearly defined set of choices. |
| Crowd Sourced Remote ID |
|
|
This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. |
| Methods for Remotely Measuring IP Spoofing Capability |
|
|
This document summarizes and standardizes methods for remotely measuring a network's IP spoofing capability. For outbound spoofing capability measurement, i.e., whether the network allows IP spoofing traffic to be sent from inside the network to the outside of the network, DNS traceroute can be used to check whether spoofed packets are generated in the network and sent to outside of the network. For inbound spoofing capability measurment, i.e., whether the network allows IP spoofing traffic from the outside the network to arrive inside, DNS resolver and ICMPv6 rate limiting mechanism can be utilized to check whether spoofed packets are received by devices in the network. |
| Privacy Pass Issuance Protocols with Public Metadata |
|
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
| Multipath Extension for QUIC |
|
| draft-ietf-quic-multipath-07.txt |
| Date: |
10/04/2024 |
| Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-lmbdhk-quic-multipath. |
|
|
| |
| Preference for IPv6 ULAs over IPv4 addresses in RFC6724 |
|
|
When RFC 6724 was published it defined an address selection algorithm along with a default policy table, and noted a number of examples where that policy table might benefit from adjustment for specific scenarios. It also noted that it is important for implementations to provide a way to change the default policies as more experience is gained. This update draws on several years of operational experience to refine RFC 6724 further, with particular emphasis on preference for the use of ULA addresses over IPv4 addresses and the addition of mandatory support for Rule 5.5. The update also demotes the preference for 6to4 addresses. The changes to default behavior improve supportability of common use cases, including automatic / unmanaged scenarios. It is recognized that some less common deployment scenarios may require explicit configuration or custom changes to achieve desired operational parameters. |
| BFD Encapsulated in Large Packets |
|
|
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. |
| Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) |
|
| draft-ietf-core-oscore-edhoc-11.txt |
| Date: |
09/04/2024 |
| Authors: |
Francesca Palombini, Marco Tiloca, Rikard Hoeglund, Stefan Hristozov, Goeran Selander |
| Working Group: |
Constrained RESTful Environments (core) |
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. |
| PCEP Procedures and Extension for VLAN-based Traffic Forwarding |
|
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. |
| Trusted Domain SRv6 |
|
|
SRv6 as designed has evoked interest from various parties, though its deployment is being limited, amongst other things, by known security problems in its architecture. This document specifies a standard way to create a solution that closes some of the major security concerns, while retaining the tenants of the SRv6 protocol. |
| High Assurance DIDs with DNS |
|
|
This document outlines a method for improving the authenticity, discoverability, and portability of Decentralized Identifiers (DIDs) by utilizing the current DNS infrastructure and its technologies. This method offers a straightforward procedure for a verifier to cryptographically cross-validate a DID using data stored in the DNS, separate from the DID document. |
| Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses |
|
| draft-sipcore-rfc7976bis-01.txt |
| Date: |
09/04/2024 |
| Authors: |
Christer Holmberg, Nevenka Biondic, Gonzalo Salgueiro, Roland Jesske |
| Working Group: |
Individual Submissions (none) |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
| Proof of Issuer Key Authority (PIKA) |
|
|
A relying party verifying a JSON Web Token (JWT) needs to verify that the public key used to verify the signature legitimately represents the issuer represented in the "iss" claim of the JWT. Today, relying parties commonly use the "iss" claim to fetch a set of authorized signing keys over HTTPS, relying on the security of HTTPS to establish the authority of the downloaded keys for that issuer. The ephemerality of this proof of authority makes it unsuitable for use cases where a JWT might need to be verified for some time. In this document, we define a format for Proofs of Issuer Key Authority, which establish the authority of a key using a signed object instead of an HTTPS connection. |
| SRv6 Resource Programming with NRP flavor |
|
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes |
|
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with attributes signaling validation state may flood needless BGP UPDATE messages through the global Internet routing system, when, for example, Route Origin Authorizations are issued, revoked, or RPKI-To- Router sessions are terminated. Operators SHOULD ensure Validation States are not signalled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT group BGP routes by their Prefix Origin Validation state into distinct BGP Communities. |
|
|
| |
| RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
|
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| Internet Message Format |
|
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
| Protocol Numbers for SCHC |
|
|
This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. |
| A Decent LISP Mapping System (LISP-Decent) |
|
|
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. |
| Crowd Sourced Remote ID |
|
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. |
| Revised Cookie Processing in the IKEv2 Protocol |
|
|
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. |
| 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 Registry Interfaces |
|
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. |
| ICANN Registrar Interfaces |
|
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. |
| The Incident Detection Message Exchange Format version 2 (IDMEFv2) |
|
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. |
| Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS |
|
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. |
| Terminal-based joint selection and configuration of MEC host and RAW network |
|
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| Extensions to enable wireless reliability and availability in multi-access edge deployments |
|
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| MIPv6 RAW mobility |
|
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| RAW multidomain extensions |
|
|
This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. |
| Discovery of Network Rate-Limit Policies (NRLPs) |
|
|
Traffic exchanged over a network attachment may be subject to rate- limit policies. These policies may be intentional policies (e.g., enforced as part of the activation of the network attachment and typically agreed upon service subscription) or be reactive policies (e.g., enforced temporarily to manage an overload or during a DDoS attack mitigation). Networks already support mechanisms to advertize a set of network properties to hosts using Neighbor Discovery options. Examples of such properties are link MTU (RFC 4861) and PREFIX64 (RFC 8781). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate these policies to hosts. For address family parity, a new DHCP option is also defined. |
|
|
| |
| 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. |
| ICMP Extensions for Environmental Information |
|
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental impact information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental- impact metrics. |
| MIMI Metadata Minimalization (MIMIMI) |
|
|
This document describes a proposal to run the MIMI protocol in a way that reduces the ability of the Hub and service providers to associate messaging activity of clients with their respective identities. For now, this document only contains a high-level description of the mechanisms involved. |
| Secure Asset Transfer Protocol (SATP) Core |
|
| draft-ietf-satp-core-04.txt |
| Date: |
05/04/2024 |
| Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior |
| Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| Detecting RRDP Session Desynchronization |
|
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. |
| Hybrid key exchange in TLS 1.3 |
|
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. |
| Best Current Practice for Workload Identity |
|
|
The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and client_secret, can be complex and error-prone. "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads. This document specifies the use of JWTs for client credentials in container orchestration systems to improve interoperability in orchestration systems, to reduce complexity for developers, and motivates authorization server to support RFC 7523. |
|
|
| |
| WebP Image Format |
|
| draft-zern-webp-15.txt |
| Date: |
04/04/2024 |
| Authors: |
James Zern, Pascal Massimino, Jyrki Alakuijala |
| Working Group: |
Applications and Real-Time Area (art) |
|
This document defines the WebP image format and registers a media type supporting its use. |
| IMAP Extension for only using and returning UIDs |
|
| draft-ietf-extra-imap-uidonly-08.txt |
| Date: |
04/04/2024 |
| Authors: |
Alexey Melnikov, ArunPrakash Achuthan, Vikram Nagulakonda, Ashutosh Singh, Luis Alves |
| Working Group: |
Email mailstore and eXtensions To Revise or Amend (extra) |
|
The UIDONLY extension to the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses, and can't be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs. This document defines an experimental IMAP extension. |
| IMAP4 Response Code for Command Progress Notifications. |
|
|
This document defines a new IMAP untagged response code, "INPROGRESS", that provides structured numeric progress status indication for long-running commands. |
| JMAP for Sieve Scripts |
|
|
This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Clients can use this protocol to efficiently search, access, organize, and validate Sieve scripts. |
| Clarification of RFC7030 CSR Attributes definition |
|
| draft-ietf-lamps-rfc7030-csrattrs-09.txt |
| Date: |
04/04/2024 |
| Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. |
| No Revocation Available for X.509 Public Key Certificates |
|
| draft-ietf-lamps-norevavail-04.txt |
| Date: |
04/04/2024 |
| Authors: |
Russ Housley, Tomofumi Okubo, Joseph Mandel |
| Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
X.509v3 public key certificates are profiled in RFC 5280. Short- lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm in RFC 5280 to skip revocation checking when the noRevAvail certificate extension is present. |
| YANG Groupings for TCP Clients and TCP Servers |
|
|
This document presents three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. |
| Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix |
|
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. |
| Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution |
|
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. |
| Multiple IPv4 - IPv6 mapped IPv6 address (M46A) |
|
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. |
| Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) |
|
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. |
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) |
|
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. |
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) |
|
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| Multiple IPv4 - IPv6 address mapping translator (M46T) |
|
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. |
| Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E) |
|
|
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. |
| Multi-Stage Transparent Server Load Balancing |
|
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. |
| Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) |
|
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. |
| ESP Echo Protocol |
|
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| Gender Representation in the IETF Nominating Committees |
|
|
This document extends the existing limit on nomcom representation by company in order to improve gender diversity by ensuring that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. |
| Registry policies "... with Expert Review" |
|
|
This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. |
| 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. |
|
|
| |
| COSE "typ" (type) Header Parameter |
|
|
This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) typ (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing, as defined in the JSON Web Token Best Current Practices BCP, to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. |
| IMAP4 Extension for Returning Mailbox METADATA in Extended LIST |
|
|
This document defines an extension to the to IMAP LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. |
| Federated TLS Authentication |
|
|
This document describes the Federated TLS Authentication (FedTLS) protocol, enabling secure end-to-end communication within a federated environment. Both clients and servers perform mutual TLS authentication, establishing trust based on a centrally managed trust anchor published by the federation. Additionally, FedTLS ensures unambiguous identification of entities, as only authorized members within the federation can publish metadata, further mitigating risks associated with unauthorized entities impersonating legitimate participants. This framework promotes seamless and secure interoperability across different trust domains adhering to common policies and standards within the federation. |
| Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages |
|
|
This document describes a PTP Profile for the use of the Precision Time Protocol in an IPv4 or IPv6 Enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allows both multicast and unicast Delay Request and Delay Response messages. |
| TLS 1.2 is in Feature Freeze |
|
|
TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, no new features will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |
| Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks |
|
|
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD, RFC8415). |
|
|
| |
| A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services |
|
|
This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types of network resources. |
| Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
|
| draft-ietf-bess-evpn-dpath-00.txt |
| Date: |
02/04/2024 |
| Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| An Architecture for More Instant Messaging Interoperability (MIMI) |
|
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. |
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
|
| draft-ietf-mimi-protocol-00.txt |
| Date: |
02/04/2024 |
| Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| OSPF Abnormal State Information |
|
|
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. |
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path |
|
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. |
| Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path |
|
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. |
| A Forward-Search P2P TE LSP Inter-Domain Path Computation |
|
|
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| A Forward-Search P2MP TE LSP Inter-Domain Path Computation |
|
|
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks. |
|
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. |
| Extensions to PCEP for Distributing Label Cross Domains |
|
|
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). |
| BGP Extensions for IDs Allocation |
|
|
This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed. |
| BGP-SPF Flooding Reduction |
|
|
This document describes extensions to Border Gateway Protocol (BGP) for flooding the link states on a topology that is a subgraph of the complete topology of a BGP-SPF domain, so that the amount of flooding traffic in the domain is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. |
| IGP Extensions for Advertising Node Index |
|
| draft-chen-lsr-adv-ni-04.txt |
| Date: |
02/04/2024 |
| Authors: |
Huaimo Chen, Donald Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu |
| Working Group: |
Individual Submissions (none) |
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. |
| SR-MPLS FRR Extension |
|
|
The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node on an SR-MPLS path by the neighbor upstream node as point of local repair (PLR) of the failed node. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbor upstream node of the failed node will no longer have a route to the failed node. This document describes a simple mechanism to extend the fast re-route protection for the failure on an SR-MPLS path after the IGP converges. The mechanism protects the node SID, adjacency SID and binding SID of the failed node on the path. |
| External Keys For Use In Internet X.509 Certificates |
|
|
Many of the post quantum cryptographic algorithms have large public keys. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and algorithms for referencing external public key data by hash, and location, for example URL. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. |
| Security and Privacy Implications of 3GPP AI/ML Networking Studies for 6G |
|
|
This document provides an overview of 3GPP work on Artificial Intelligence/ Machine Learning (AI/ML) networking. Application areas and corresponding proposed modifications to the architecture are identified. Security and privacy issues of these new applications need to be identified out of which IETF work could emerge. |
| Closing the RTP Payload Format Media Types IANA Registry |
|
|
It has been observed that specifications of new RTP payload formats often forget to register themselves in the IANA regsitry "RTP Payload Formats Media Types". In practice this has no real impact. One reason is that the Media Types registry is the crucial regsistry to register any Media Type to establish the media type used to identified the format in various signalling usage. To resolve this sitaution this document performs the following. First it updates the registry to include known RTP payload formats at the time of writing. Then it closes the IANA Registry for RTP Payload formats Media Types for future registration. Beyond instructing IANA to close this registry the instructions to authors in RFC 8088 are updated that registration is no longer required in the closed registry. |
| Proposal for the Introduction of Email Headers for Phishing Detection Training |
|
|
This document proposes the addition of new email headers designed specifically to identify emails that are sent as part of phishing detection training programs. These headers would allow recipients to verify the authenticity of training emails using DNS queries to confirm that the sending domains are authorized to send these types of emails. |
| DataRight+: Admission Control Baseline |
|
|
The establishment of a shared model of trust is critical to any functioning technology ecosystem, particularly when it relates to the sharing of data and the execution of Consumer specific actions. Traditional models of trust have typically revolved around implicit trust established through bi-lateral arrangements (i.e. legal contracts) between participants. The issue with this approach is that, at scale, it is not possible for all participants to efficiently establish communication with all other participants. This leads to the requirement for a mechanism to establish trust across participants in a way that the business layer of an organisation has confidence in ensuring participant interaction is validated. |
| DataRight+: Australian CDR Profile |
|
|
This is the ecosystem profile for the Australian CDR describing the composite components to form the technical infrastructure operating to form the Australian Consumer Data Right. This specification is intended to result in a [CDS] compatible implementation. Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| YANG Model for the NETCONF default attribute |
|
|
This document defines a YANG module with the "default" attribute using the namespace and prefix defined in [RFC6243]. This enables usage of the "default" attribute in e.g. YANG JSON encoding. |
| EAT Media Types |
|
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). |
|
|
| |
| Usage Limits on AEAD Algorithms |
|
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| Key Blinding for Signature Schemes |
|
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| Properties of AEAD Algorithms |
|
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. |
| DRIP Entity Tag (DET) Identity Management Architecture |
|
|
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts is performed via DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. |
| The Link-Template HTTP Header Field |
|
|
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. |
| Multicast On-path Telemetry using IOAM |
|
|
This document specifies the requirements of on-path telemetry for multicast traffic using In-situ OAM. While In-situ OAM is advantageous for multicast traffic telemetry, some unique challenges are present. This document provides the solutions based on the In- situ OAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. |
| The FNV Non-Cryptographic Hash Algorithm |
|
| draft-eastlake-fnv-22.txt |
| Date: |
01/04/2024 |
| Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that is referenced in a number of standards documents and widely used. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. |
| IPv6 is Classless |
|
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. |
| Information Awareness System for Computing-Aware Service Function Chain (IAS-CASFC): Security Service Aspect |
|
|
This document describes the Information Awareness System of the Computing-Aware Service Function Chain (ISA-CASFC) from the security service aspect, including the system architecture, network, and computing information details. The SFC enables traffic to pass through the ordered Network Security Function (NSF) path, enabling end-to-end security services. Differences in the available network and computing resources cause performance differences between NSF instances deployed on different service sites. It can be seen that the routing decision on NSF instances will affect the quality of the security service. Therefore, it is necessary to implement the CA-SFC to ensure the quality of security service. This document extends the CATS framework and the CATS Computing and Network Information Awareness (CNIA) architecture for CA-SFC, and describes the network and computing information content for security service. |
| DataRight+: Energy Resource Set |
|
|
This is the resource set profile outlining the energy sector related endpoints. In addition to outlining Initiator and Provider provisions it also specifies requirements for the Energy Authority (electricity assets and usage) and Energy Plan Website (retail electricity plan information). Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+: Common Resource Set |
|
|
This is the resource set profile outlining the common endpoints utilised across multiple industries. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+: Banking Resource Set |
|
|
This is the resource set profile outlining the banking sector related endpoints. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| DataRight+ Security Profile: Baseline |
|
|
The DataRight+ Security Profile: Baseline is intended to be a compatible profile of the [CDS] presented as a profile of [FAPI-1.0-Advanced]. This profile focuses primarily on the obligations between Provider and Initiator with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of specified authorisation types. This profile does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the [CDS]. Further terminology used is deliberately jurisdiction agnostic, please refer to [DATARIGHTPLUS-ROSETTA] for specific ecosystem mappings. |
| DataRight+: Sharing Arrangement V1 |
|
|
This specification outlines the technical requirements related to the delivery of Sharing Arrangement V1. Notational Conventions The keywords "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. |
| IGMP and MLD Snooping Yang Module Extension for L2VPN |
|
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. |
| Rate-Limited Token Issuance Protocol |
|
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. |
| The PrivateToken HTTP Authentication Scheme Extensions Parameter |
|
|
This document specifies a new parameter for the "PrivateToken" HTTP authentication scheme. This purpose of this parameter is to carry extensions for Privacy Pass protocols that support public metadata. |
| 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. |