|
|
| |
| Seamless Multicast Interoperability between EVPN and MVPN PEs |
|
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) and Enterprise networks as well as the next generation VPN services in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| A YANG model to manage the optical interface parameters for an external transponder in a WDM network |
|
| draft-ietf-ccamp-dwdm-if-param-yang-10.txt |
| Date: |
23/10/2023 |
| Authors: |
Gabriele Galimberti, Dharini Hiremagalur, Gert Grammel, Roberto Manzotti, Dirk Breuer |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. Is to be noted that the Transceivers can be located on the Transponders (optical layer) or on the Router (in general packet layer) in form of Pluggable modules. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. |
| CBOR Object Signing and Encryption (COSE) Key Thumbprint |
|
|
This specification defines a method for computing a hash value over a COSE Key. It defines which fields in a COSE Key structure are used in the hash computation, the method of creating a canonical form of the fields, and how to hash the byte sequence. The resulting hash value can be used for identifying or selecting a key that is the subject of the thumbprint. |
| BGP Flow Specification Version 2 |
|
| draft-ietf-idr-flowspec-v2-03.txt |
| Date: |
23/10/2023 |
| 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. |
| A summary of security-enabling technologies for IoT devices |
|
|
The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies. |
| Extension Formatting for the Opus Codec |
|
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. |
| IPv6-only Terminology Definition |
|
|
This document defines the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. |
| IGP Extensions for Scalable Segment Routing based Virtual Transport Network (VTN) |
|
|
Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used to support one or a group of VPN+ services. In the context of network slicing, a VTN could be instantiated as a network resource partition (NRP). This document specifies the IGP mechanisms with necessary extensions to advertise the associated topology and resource attributes for scalable Segment Routing (SR) based NRPs. Each NRP can have a customized topology and a set of network resources allocated from the physical network. Multiple NRPs may shared the same topology, and multiple NRPs may share the same set of network resources on some network segments. This allows flexible combination of the network topology and network resource attributes to build a relatively large number of NRPs with a relatively small number of logical topologies. A group of resource-aware SIDs and SRv6 Locators can be assigned to each NRP. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and Segment Routing with IPv6 data plane (SRv6). This document also describes the mechanism of using dedicated NRP ID in the data plane instead of the per-NRP resource-aware SIDs and SRv6 Locators to further reduce the control plane and data plane overhead of maintaining a large number of NRPs. |
| Framework for In-situ Flow Information Telemetry |
|
|
As network scale increases and network operation becomes more sophisticated, existing Operation, Administration, and Maintenance (OAM) methods are no longer sufficient to meet the monitoring and measurement requirements. Emerging data-plane on-path telemetry techniques, such as IOAM and AltMrk, which provide high-precision flow insight and issue notifications in real time can supplement existing proactive and reactive methods that run in active and passive modes. They enable quality of experience for users and applications, and identification of network faults and deficiencies. This document describes a reference framework, named as In-situ Flow Information Telemetry, for the on-path telemetry techniques. The high-level framework outlines the system architecture for applying the on-path telemetry techniques to collect and correlate performance measurement information from the network. It identifies the components that coordinate existing protocol tools and telemetry mechanisms, and addresses deployment challenges for flow-oriented on- path telemetry techniques, especially in carrier networks. The document is a guide for system designers applying the referenced techniques. It is also intended to motivate further work to enhance the OAM ecosystem. |
| BGP-LS Extensions for Scalable Segment Routing based Enhanced VPN |
|
|
Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the resources and characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which can be used to support one or a group of VPN+ services. In the context of network slicing, a VTN could be instantiated as a network resource partition (NRP). This document specifies the BGP-LS mechanisms with necessary extensions to advertise the information of scalable Segment Routing (SR) based NRPs to a centralized network controller. Each NRP can have a customized topology and a set of network resources allocated from the physical network. Multiple NRPs may shared the same topology, and multiple NRPs may share the same set of network resources on specific network segments. This allows flexible combination of network topology and network resource attributes to build a large number of NRPs with a relatively small number of logical topologies. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| Conveying Transceiver-Related Information within RSVP-TE Signaling |
|
|
The ReSource reserVation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. |
| LTP Fragmentation |
|
|
The Licklider Transmission Protocol (LTP) provides a reliable datagram convergence layer for the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol. In common practice, LTP is often configured over UDP/IP sockets and inherits its maximum segment size from the maximum-sized UDP/IP datagram, however when this size exceeds the path maximum transmission unit a service known as IP fragmentation must be engaged. This document discusses LTP interactions with IP fragmentation and mitigations for managing the amount of IP fragmentation employed. |
| 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 in the Internet of Things. 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 format and a compact format (Annex C), this specification defines a compact format to go along SDF's JSON 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. |
| Extending ICMP for IP-related Information Validation |
|
|
This document introduces the mechanism to verify the data plane against the control plane in IPv6/SRv6 networks by extending ICMPv6 messages. |
| IETF Network Slice Deployment Status and Considerations |
|
|
Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided. |
| RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6 |
|
|
This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. |
| TCPLS: Modern Transport Services with TCP and TLS |
|
| draft-piraux-tcpls-04.txt |
| Date: |
23/10/2023 |
| Authors: |
Maxime Piraux, Florentin Rochet, Olivier Bonaventure |
| Working Group: |
Individual Submissions (none) |
|
This document specifies a protocol leveraging TCP and TLS to provide modern transport services such as multiplexing, connection migration and multipath in a secure manner. 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/mpiraux/draft-piraux-tcpls. |
| RLB (Replication through Local Bitstring) Segment for Multicast Source Routing over IPv6 |
|
|
This document defines 2 new types of segment: End.RLB.X and End.RLB, and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions. |
| Considerations of deploying AI services in a distributed method |
|
| draft-hong-nmrg-ai-deploy-05.txt |
| Date: |
23/10/2023 |
| Authors: |
Yong-Geun Hong, Oh Seokbeom, Joo-Sang Youn, SooJeong Lee, Seung-Woo Hong, Ho-Sun Yoon |
| Working Group: |
Individual Submissions (none) |
|
As the development of AI technology matured and AI technology began to be applied in various fields, AI technology is changed from running only on very high-performance servers with small hardware, including microcontrollers, low-performance CPUs and AI chipsets. In this document, we consider how to configure the network and the system in terms of AI inference service to provide AI service in a distributed method. Also, we describe the points to be considered in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying AI services in a distributed method such as self-driving car and digital twin network are described. |
| A YANG Data Model for Open Shortest Path First (OSPF) Topology |
|
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Open Shortest Path First (OSPF) information. This document augments the 'ietf- network' data model by adding OSPF concepts and explains how the data model can be used to represent the OSPF topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| DetNet Enhanced Data Plane |
|
|
Aiming at providing the bounded latency to DetNet services, DetNet data plane is required to be enhanced. This document provides a method to extend DetNet data plane by introducing the Bounded Latency Information (BLI), which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. |
| Performance-Oriented Digital Twins for Packet and Optical Networks |
|
|
This draft introduces the concept of a Network Digital Twin (NDT), including the architecture as well as the interfaces. Then two specific instances of the NDT are introduced, the first one for packet networks. This produces performance estimates (delay, jitter, loss) for a packet network with a specified topology, traffic demand, and routing and scheduling configuration. Second, a NDT for optical networks, this produces transmission performance estimates of an optical network with specified optical service topologies and network equipment types, topology and status. |
| Problem statement for Inter-domain Intent-aware Routing using Color |
|
|
This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions. |
| Real-Time Monitoring Link/Protocol Neighbor State |
|
|
Various protocols are deployed in today's networks, such as BGP / ISIS / OSPF etc. Link neighbor state changes and protocol neighbor state changes are the most important network events that need to be processed with the highest priority. In particular, the SDN controller needs to quickly sense the link neighbor and protocol neighbor state change information in the network. Thus, the various policies applied by the SDN controller to the network can quickly match the current state of the network. This document discusses some possible scenarios and the relevant requirements. |
| Forward Erasure Correction for QUIC loss recovery |
|
|
This documents lays down the QUIC protocol design considerations needed for QUIC to apply Forward Erasure Correction on the data sent through the network. |
| IPsec and IKE anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing |
|
|
This document discusses the challenges of running IPsec with anti- replay in multi-core environments where packets may be re-ordered (e.g., when sent over multiple IP paths, traffic-engineered paths and/or using different QoS classes). A new solution based on splitting the anti-replay sequence number space into multiple different sequencing subspaces is proposed. Since this solution requires support on both parties, an IKE extension is proposed in order to negotiate the use of the anti-replay sequence number subspaces. |
| A Taxonomy of Internet Consolidation |
|
|
This document contributes to the ongoing discussion surrounding Internet consolidation. At recent IETF meetings discussions about Internet consolidation revealed that different perspectives gave completely different views of what consolidation means. While we use the term consolidation to refer to the process of increasing control over Internet infrastructure and services by a small set of organizations, it is clear that that control is expressed through economic, network traffic and protocol concerns. As a contribution to the discussion surrounding consolidation, this document attempts to provide a taxonomy of Internet consolidation with the goal of adding clarity to a complex discussion. |
| Identity for E2E-Secure Communications |
|
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. |
| Composite Token Claims |
|
|
Composition claims are CBOR Web Token claims that define logical relationships between sets of claims and provide for private claim values via encryption. |
| IANA Registry for IMAP Extended SEARCH Return Options and Data Tags |
|
|
This document creates a registry of IMAP Extended Search Return Options and Data Tags (RFC 4466) in order to help developers and IMAP extension writers track interactions between different extensions. Open Issues * Is Expert Review the correct registration policy? * Should we also add a registry of SEARCH criteria? |
| Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) |
|
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters or additional attestations. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. |
| An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness |
|
|
This document proposes an extension to the Cooperating Layered Architecture for Software-Defined Networking (SDN) by including compute resources and data analysis processing capabilities. |
| Computing Information Description in Computing-Aware Traffic Steering |
|
|
This document describes the considerations and the potential architecture of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). |
| An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation |
|
| draft-xu-ipsecme-risav-04.txt |
| Date: |
23/10/2023 |
| Authors: |
Ke Xu, Jianping Wu, Yangfei Guo, Benjamin Schwartz, Haiyang Wang |
| Working Group: |
Individual Submissions (none) |
|
This document presents RISAV, a protocol for establishing and using IPsec security between Autonomous Systems (ASes) using the RPKI identity system. In this protocol, the originating AS adds authenticating information to each outgoing packet at its Border Routers (ASBRs), and the receiving AS verifies and strips this information at its ASBRs. Packets that fail validation are dropped by the ASBR. RISAV achieves Source Address Validation among all participating ASes. |
| Extensible Simple Authentication and Security Layer (SASL) |
|
| draft-melnikov-sasl2-01.txt |
| Date: |
23/10/2023 |
| Authors: |
Dave Cridland, Thilo Molitor, Matthew Wild, Alexey Melnikov |
| Working Group: |
Individual Submissions (none) |
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. |
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) |
|
| draft-dong-pce-pcep-nrp-01.txt |
| Date: |
23/10/2023 |
| Authors: |
Jie Dong, Sheng Fang, Quan Xiong, Shaofu Peng, Liuyan Han, Minxue Wang, Vishnu Beeram, Tarek Saad |
| Working Group: |
Individual Submissions (none) |
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. |
| IP Addressing Considerations |
|
|
The Internet Protocol (IP) has been the major technological success in information technology of the last half century. As the Internet becomes pervasive, IP has been replacing communication technology for many domain-specific solutions, but it also has been extended to better fit the specificities of the different use cases. For Internet addressing in particular, as it is defined in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively, there exist many extensions. Those extensions have been developed to evolve the addressing capabilities beyond the basic properties of Internet addressing. This document discusses the properties the IP addressing model, showcasing the continuing need to extend it and the methods used for doing so. |
| Aircraft to Anything AdHoc Broadcasts and Session |
|
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that 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 a lower cost symmetric key protect flow can be used. This document shows both how to secure A2X broadcast messages with DRIP DET and Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for using X.509 certificates, encoded in c509, as an alternative DET trust model. |
| MIMI Terminology |
|
|
This document introduces a set of terminology to use when discussing or describing concepts within MIMI. |
| Jitter Reduction Mechanism for DetNet |
|
|
In large-scale deterministic networks (LDN), App-flows need to span multiple deterministic network domains, and the latency in multiple domains is added together. The jitter will be increased. In order to realize the protection service function, App-flows should be transmitted on multiple paths. The delay difference in data transmission on different paths is no different from jitter in end- to-end services. Jitter generated by various factors needs to be controlled to meet business requirements. This document describes the end-to-end jitter reduction mechanism in an LDN. This mechanism can effectively control the end-to-end jitter to meet specific business needs and make the planning of multiple paths for service protection more flexible. |
| Inter-domain Source Address Validation based on AS relationships |
|
|
This draft introduces an inter-domain source address validation scheme based on relationships between interconnected ASes. This scheme is mainly described from four aspects, namely the research background in fields of source address validation and AS relationships, introduction to the classification and acquisition methods of AS relationships, the specific architecture of our inter- domain source address validation system based on AS relationships, and the considerations on deployability. |
| Guidelines for Internet Congestion Control at Endpoints |
|
|
When published as an RFC, this document provides guidance on the design of methods to avoid congestion collapse and how an endpoint needs to react to congestion. Based on these, and Internet engineering experience, the document provides best current practice for the design of new congestion control methods in Internet protocols. When published, the document will update or replace the Best Current Practice in BCP 41, which currently includes "Congestion Control Principles" provided in RFC2914. |
| Reverse HTTP Transport |
|
| draft-bt-httpbis-reverse-http-01.txt |
| Date: |
23/10/2023 |
| Authors: |
Benjamin Schwartz, Tirumaleswar Reddy.K, Mohamed Boucadair, Philipp Tiesel |
| Working Group: |
Individual Submissions (none) |
|
This document defines a secure transport for HTTP in which the client and server roles are reversed. This arrangement improves the origin server's protection from Layer 3 and Layer 4 denial-of-service attacks when an intermediary is in use. It allows origin server's to be hosted without being publicly (and directly) accessible but allows clients to access these servers via an intermediary. |
| Traffic Engineering Extensions for Enhanced DetNet |
|
|
As per [I-D.ietf-teas-rfc3272bis], DetNet can also be seen as a specialized branch of TE. As it is required to provide enhancements for data plane in scaling networks, this document proposes a set of extensions for traffic engineering to achieve the differentiated DetNet QoS in enhanced DetNet. |
| Computing resource notification domain in network |
|
|
This document introduces the definiation and the requirements of notification domain, and also introduces the process of service scheduling decision based on the notification domain in the network. |
| AI-Based Distributed Processing Automation in Digital Twin Network |
|
| draft-oh-nmrg-ai-adp-01.txt |
| Date: |
23/10/2023 |
| Authors: |
Oh Seokbeom, Yong-Geun Hong, Joo-Sang Youn, Hyunjeong Lee, Hyun-Kook Kahng |
| Working Group: |
Individual Submissions (none) |
|
This document discusses the use of AI technology and digital twin technology to automate the management of computer network resources distributed across different locations. Digital twin technology involves creating a virtual model of real-world physical objects or processes, which is utilized to analyze and optimize complex systems. In a digital twin network, AI-based network management by automating distributed processing involves utilizing deep learning algorithms to analyze network traffic, identify potential issues, and take proactive measures to prevent or mitigate those issues. Network administrators can efficiently manage and optimize their networks, thereby improving network performance and reliability. AI-based network management, utilizing digital twin network technology, also aids in optimizing network performance by identifying bottlenecks in the network and automatically adjusting network settings to enhance throughput and reduce latency. By implementing AI-based network management through automated distributed processing, organizations can improve network performance, and reduce the need for manual network management tasks. |
| BRSKI-CLE: A Certificateless Enrollment framework in BRSKI |
|
|
The Class 1 constrained IoT devices, defined in RFC7228, may be unable to use certificates within limited RAM. Exiting enrollment protocols of BRSKI are all using certificates. This document defines a certificateless enrollment framework in BRSKI (BRSKI-CLE) for constrained IoT devices. Considering the evolution towards quantum- safe algorithms, the framework is based on Key Encapsulation Mechanism (KEM). Cooperating with the authentication mechanism shown in I-D.selander-lake-authz, a constrained IoT device does not need to configure a public key to identify itself for the whole bootstrapping process. An authentication centre (AC) is used for issuing lightweight credentials, such as CBOR Web Tokens (CWTs), to constrained IoT devices. This document does not specify any lightweight credentials. |
| The Use of Attestation in OAuth 2.0 Dynamic Client Registration |
|
|
The OAuth 2.0 Dynamic Client Registration specification described in RFC 7591 describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain information to interact with this authorization server, including an OAuth 2.0 client identifier. To offer proper security protection for this dynamic client registration some security credentials need to be available on the OAuth 2.0 client. For this purpose RFC 7591 relies on two mechanisms, a trust-on-first-use model and a model where the client is in possession of a software statement (a sort-of bearer token). This specification improves the security of the OAuth 2.0 Dynamic Client Registration specification by introducing the support of attestation. |
| Signaling-based configuration for supporting multiple upstream interfaces in IGMP/MLD proxies |
|
|
The support of multiple upstream interfaces in IGMP/MLD proxies requires the capability of configuring the different upstream interfaces for specific multicast channels/sessions. Recently [RFC9279] has defined a message extension mechanism for IGMP and MLD. This document leverages on that for proposing extension for signaling-based configuration the multiple upstream interfaces in IGMP/MLD proxies. |
| Encoding 3GPP Slices for Interactive Media Services |
|
|
Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in the 3GPP SA2 working group. It targets at achieving high data rate, ultra-low latency, and high reliability. The streams of an XRM service might be comprised of data from multiple modalities, namely, video, audio, ambient-sensor and haptic detection, etc. XRM service faces challenges on various aspects, e.g. accurate multi-modality data synchronization, QoS differentiation, large volume of packets, and etc. While a new 3GPP network slice type, HDLLC, has been recently introduced to handle the QoS requirements of XRM streams, the ubiquitously-existential encryption of packet header and/or payload post additional challenges to the transport of encoded video packets via 5GS. We have then discussed two potential IETF schemes, e.g., IP-DSCP based or UDP-option extension, that could be applied to 'expose' XRM QoS 'metadata' to 5GS. |
| DNS IPv6 Transport Operational Guidelines |
|
|
This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. |
| Metaverse and ICN: Challenges and Use Cases |
|
|
This document considers some challenges for ICN support of Metaverse- type applications from a networking perspective. Also, one use case is presented to promote one of our future visions. |
| Lightweight Bundle Protocol Edge Node with Zero-Configuration and Zero-State |
|
|
This document explains how to use existing protocols, registries, code points, and algorithms to operate a Bundle Protocol (BP) edge node within a stable, non-challenged local underlayer IP network without the need for prior BP-layer configuration or long-term state. The purpose of this is to significantly lower the barrier to entry for lightweight BP edge nodes intended to act as endpoints for one (or only a few) BP applications. |
| Mounting YANG-Defined Information from Remote Datastores |
|
|
This document defines a mechanism, Peer-Mount, that allows YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that reference data nodes in other YANG subtrees and subsequently allowing those data nodes to be accessed by client applications as if they were part of the same local data hierarchy. In addition, means to manage and administer tho mount points are provided. This facilitates the development of applications that need to access network-wide data that treanscends individual network devices while ensuring network-wide data consistency. One example concerns example applications that require a network inventory and/or network topology with access to select management data within the nodes that comprise it. The concept of Peer-Mount was first introduced in an earlier Internet Draft that was no longer pursued due to lack of interest at the time. It is being revived now in light of renewed IETF interest in network inventory, network topology, and related use cases, for which Peer- Mount is of specific interest. Other concepts defined in the earlier draft, notably Alias-Mount, are not considered here since they provide other capabilities that are less applicable to those topics. |
| Problem Statement:Collaborative Defense of DDoS Attacks |
|
|
This document presents a problem statement on collaborative mitigation of Distributed Denial-of-Service (DDoS) attacks. The evolving trends of DDoS attacks, including their types, intensities, and attack methods, pose formidable challenges to existing defense systems. This problem statement examines the current defense landscape, highlighting the distributed deployment of defense systems across various network positions and the imbalances in defense capabilities. Collaboration is crucial for effective DDoS attack mitigation, considering that a considerable number of attacks are spread across operators. The existing collaborative framework, DOTS, shows promise but requires addressing these challenges to enhance its efficacy. The existing collaborative framework DOTS demonstrates potential, but there are still numerous challenges in its practical application. This document aims to address these key issues that impact the implementation of collaborative technologies. |
| Collective Communication Optimization: Problem Statement and Use cases |
|
|
Collective communication is the basic logical communication model for distributed applications. When distributed systems scales, the communication overhead becomes the bottleneck of the entire system, impeding system performance to increase. This draft describes the performance challenges when the collective communication is employed in a network with more nodes or processes participating in or a larger number of such communication rounds required to complete a single job. And the document presents several use cases where different aspects of collective communication optimization are needed. |
| SRv6 Migration Scenarios |
|
|
SRv6 forwarding plane requires devices to support processing newly defined Segment Routing extension header. All devices in the network may not be capable of processing this new header and may require gradual upgrade. This document specifies mechanisms that to deploy features such as TI-LFA, in the presence of SRH incapable devices in the network. |
| Data Model for Asset Lifecycle Management and Operations |
|
| draft-palmero-ivy-dmalmo-00.txt |
| Date: |
23/10/2023 |
| 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. |
| Enhanced Use cases for Scaling Deterministic Networks |
|
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience Video and computing-aware applications, and analyzes the classification for the three typical use cases and applications. |
| Differentiated DetNet QoS for Deterministic Services |
|
|
This document describes the service requirements of scaling deterministic networks and proposes Differentiated DetNet QoS (DD- QoS) for deterministic services in enhanced DetNet. |
| IGP Extensions for DetNet Deterministic Links |
|
|
This document proposes the deterministic links to provide a one- dimensional deterministic metric to guarantee the deterministic forwarding capabilities at different levels and proposes the deterministic links distribution by IGP extensions. |
| Necessity of Application-Network Collaboration in Wireless Access Scenarios |
|
|
Emerging applications (e.g., extended reality, cloud gaming, and teleoperation) impose stringent bandwidth, latency, reliability requirements on network transport, so as to deliver immersive and interactive user experience. That drives recent discussion on application-network collaboration, especially in wireless access networks. To motivate participation from content and network providers, this memo elaborates the necessity of such collaboration while focusing on wireless access scenarios. |
| Application-aware Networking (APN) for Performance Enhancement of Media Service |
|
|
This draft explores the requirements and benefits of carrying media metadata in the network layer (i.e. IP packets) by following the Application-aware Networking (APN) framework with extension for the application side, and defines the specific carrying information and format. |
| Proposed Update to BGP Link-State SPF NLRI Selection Rules |
|
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some update to the BGP-LS-SPF NLRI selection rules, so as to ensure a deterministic selection result. The proposed update can also help to mitigate some issues in BGP-LS-SPF route convergence. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp- spf. |
| Framework of Forwarding Commitment BGP |
|
|
This document defines a standard profile for the framework of Forwarding Commitment BGP (FC-BGP). Forwarding Commitment(FC)is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, the goal of FC-BGP is to build a secure inter-domain system that can simultaneously authenticate AS_PATH attribute in BGP-UPDATE and validate network forwarding on the dataplane. |
| Framework of Forwarding Commitment BGP |
|
|
This document defines a standard profile for the framework of Forwarding Commitment BGP (FC-BGP). Forwarding Commitment(FC)is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, the goal of FC-BGP is to build a secure inter-domain system that can simultaneously authenticate AS_PATH attribute in BGP-UPDATE and validate network forwarding on the dataplane. |
| Considerations for Adjustments of Encapsulating Security Payload (ESP) Trailer |
|
|
Implementing IPsec in hardware is a way to improve the forwarding performance of IPsec. However, the current IPsec ESP packet design, i.e., the position of ESP trailer, imposes a new overhead challenge for implementing IPsec in hardware. This document explains how this overhead challenge occurs and proposes the possible solutions. |
| Application-aware Networking (APN6) Header Authentication |
|
| draft-liu-apn-header-auth-00.txt |
| Date: |
23/10/2023 |
| Authors: |
liuy619@chinaunicom.cn, Shuai Zhang, Changwang Lin, Mengxiao Chen |
| Working Group: |
Individual Submissions (none) |
|
This document proposes an authentication method to verify the application-aware networking (APN) header. |
| IKEv2 support for specifying a Delete notify reason |
|
|
This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). |
| On the Operational Granularity of RPKI ROA Management: Problem Statement and Requirements |
|
|
When using the Resource Public Key Infrastructure (RPKI) to perform route origin validation (ROV) with route origin authorizations (ROAs), there have been security and usability issues identified and reported. This memo revisits these issues from the perspective of the operational granularity of ROA management, demonstrates problems and their root cause with the existing ROA encoding scheme, summarizes design requirements to address them, and evaluates three potential solutions. Though neither of existing solutions satisfies all requirements, a hybrid solution composed of two existing schemes is recommended to use in ROA management. |
| Notification for Adaptive Routing |
|
|
Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and improve link reliability. Adaptive routing (AR), which is widely used in direct topology such as dragonfly, can dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, in addition for the local node to apply AR, the congestion/failure information also needs to be sent to other nodes in a timely and accurate manner, so as to enforce AR in other nodes to avoid exacerbating congestion on the path. This document specifies Adaptive Routing Notification (ARN) for disseminating congestion detection and congestion elimination proactively. |
| A YANG Data Model for WDM Tunnels |
|
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| Ultra-Low Latency Cryptography Areion |
|
|
This document specifies a series of cryptographic wide-block permutations named "Areion"[Areion] for efficient encryption and hashing of relatively short input data. Additionally, it describes AEAD scheme constructed from Areion. |
| An Approach to Expose 'Device Models'-as-'Network Models' |
|
|
This document describes an approach for exposing Device Models as Network Models (DMaNM). In particular, this document provides guidance for structuring a data model to facilitate the reuse of device models within the customer-facing interface of Software- Defined Networking (SDN) controllers. The objective of this approach is to enhance the reusability of device models in various network scenarios and ease the mapping between network/service models with device models. |
| Benchmarking Methodology for Reliable Transport Protocols in Integrated Space and Terrestrial Networks |
|
|
This document defines the terminology and methodology for conducting performance benchmarking of the transport protocols for low-earth orbit satellite user terminals within emerging integrated space and terrestrial networks (ISTN). It encompasses the test environment setup and benchmarking tests. The objective of this document is to enhance the applicability, repeatability, and transparency of performance benchmarking for transport protocols in ISTN. |
| RTP Payload Format for Geometry-based Point Cloud Compression |
|
|
This memo describes an RTP payload format for geometry-based point cloud compression (G-PCC) ([ISO.IEC.23090-9]). The RTP payload format defined in this document supports the packetization of one or more data units in an RTP packet payload and the fragmentation of a single data unit into multiple RTP packets. This memo also describes congestion control for a practical solution for the real-time streaming of point clouds. Finally, the document defines parameters that may be used to select optional features of the payload format or signall properties of the RTP stream. The parameters can be used with Session Description Protocol (SDP). |
| System for Cross-domain Identity Management: Definitions,Overview,Concepts,and Requirements |
|
|
This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. |
| X.509-based Attestation Evidence |
|
|
This document specifies Claims for use within X.509 certificates. These X.509 certificates are produced by an Attester as part of the remote attestation procedures and consitute Evidence. This document follows the Remote ATtestation procedureS (RATS) architecture where Evidence is sent by an Attester and processed by a Verifier. |
| Requirements for Securing SCTP Traffic using DTLS |
|
|
The current specification of DTLS over SCTP is outdated and does not fulfill the requirements of 3GPP. This Internet Draft documents the requirements of 3GPP for securing SCTP based communications using DTLS. It is a result of a design team in TSVWG and reflects the current of its work. Therefore, this document is expected to change over time. |
| QUIC Data Channels |
|
|
WebRTC data channels provide data communication between peers with varying reliability and ordering properties. WebRTC data channels traditionally use SCTP layered on top of DTLS over UDP. This document describes how WebRTC data channels can be layered over QUIC. |
| Multiplexing RTP and Data Channels over QUIC |
|
|
This document defines a multiplexing scheme for using RTP over QUIC and QUIC Data Channels in a single QUIC connection. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mengelbart/draft-engelbart-multiplex-roq-qdc. |
| Path Validation Problem Statement,History,Gap Analysis and Use Cases |
|
|
This document provides a problem statement, history revisiting, gap analysis and use cases for path validation techniques. |
| Layer 2 Relay Agents in Cellular Fronthaul Networks |
|
|
The fronthaul portion of a cellular network is the part of the network that connects centralized radio controllers and the distributed radio units at the edge of the cellular network. A switched fronthaul network is one where the connectivity is provided through one or more stages of switches. When performing address assignment and configuration tasks in such networks, knowledge of how the different devices are connected is beneficial. Networks that employ IPv6 can use DHCPv6 to support Relay Agents. However, those networks that continue to be based on IPv4 have no easy way to support this, as the DHCPv4 support for relays is limited. This document explores how to provide Relay Agent functionality in IPv4-based switched fronthaul networks. |
| 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. |
| Safe Congestion Control |
|
|
We present criteria for evaluating Congestion Control Algorithms (CCAs) for behaviors that have the potential to cause harm to Internet applications or users. Although our primary focus is the safety of transport layer congestion control, many of these criteria should be applied to all protocol layers: entire stacks, libraries and applications themselves. |
| Security and Operational concerns in ACTN POI work |
|
|
Work in CCAMP on POI in ACTN is at an early stage and does not yet seem to have adequately described some of the operational or security concerns which may impact the real world applicability of any resulting work product |
| Structured Email: Trust and security considerations |
|
|
This document discusses trust and security considerations for "structured email" ([I-D.happel-structured-email-00]) and provides recommendations for message user agents on how to deal with structured data in email messages. |
| Kademlia-directed ID-based Routing Architecture (KIRA) |
|
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA offers highly scalable zero-touch IPv6 connectivity, i.e., it can connect hundred thousands of routers and devices in a single network (without requiring any form of hierarchy like areas). It is self-organizing to achieve a zero-touch solution that provides resilient (control plane) IPv6 connectivity without requiring any manual configuration by operators. It works well in various topologies and is loop-free even during convergence. The architecture consists of the ID-based network layer routing protocol R²/Kad in its routing tier and a Path-ID-based forwarding tier. The topological independent IDs can be embedded into IPv6 addresses, so that KIRA provides zero-touch IPv6 connectivity between KIRA nodes. |
| Differential Privacy Mechanisms for DAP |
|
|
Differential Privacy (DP) is a property of a secure aggregation mechanism that ensures that no single input measurement significantly impacts the distribution of the aggregate result. This is a stronger property than what systems like the Distributed Aggregation Protocol (DAP) are designed to achieve. This document describes a variety of DP mechansisms applicable to DAP, and, for a variety of common use cases, lifts DAP to a protocol that also achieves DP. |
| OAuth Client and Device Metadata for Nested Flows |
|
|
This specification defines a vocabulary and method of transmitting information about an OAuth client when a user is redirected through one or more authorization servers during an OAuth flow. This provides the deeper nested authorization servers with additional context that they can use for informational or revocation purposes. |
| Next Header Option in UDP Options |
|
|
This document defines the next header option in UDP options. The next header option specifies the protocol immediately following the UDP header. |
| PCEP Extension for Stateful Inter-Domain Tunnels |
|
|
This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the MPLS toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. |
| The Privacy Pass HTTP Authentication Scheme |
|
|
This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme in this document can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present Privacy Pass tokens. |
| Date and Time on the Internet: Timestamps with additional information |
|
|
This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone. It updates RFC3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see Section 2. // (This "cref" paragraph will be removed by the RFC editor:) The // present version (-11) addresses comments received during IESG // review. |
| Human Readable Validate ROA Payload Notation |
|
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| Introducing Resource Awareness to SR Segments |
|
|
This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| Out-of-Band STIR for Service Providers |
|
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a SIP request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. |
| Connected Identity for STIR |
|
|
The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. |
| IETF Network Slice Application in 3GPP 5G End-to-End Network Slice |
|
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slices have to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in management plane, control plane and data plane. |
| IETF Network Slice Controller and its associated data models |
|
| draft-ietf-teas-ns-controller-models-01.txt |
| Date: |
23/10/2023 |
| Authors: |
Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody, Sergio Belotti |
| Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. |
| Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) |
|
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). It is an improved alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and partial replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an improved alternative to RFC 6083 and removes the 16 kbytes limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of security fixes and improvements. It updates the DTLS versions and SCTP-AUTH HMAC algorithms to use. It mitigates reflection attacks of data and control chunks and replay attacks of data chunks. It simplifies secure implementation by some stricter requirements on the establishment procedures as well as rekeying to align with zero trust principles. |
| IPv6-only Capable Resolvers Utilising NAT64 |
|
|
This document outlines how IPv6-only iterative resolvers can use stateful NAT64 to establish communications with IPv4-only authoritative servers. It outlines a mechanism for translating the IPv4 addresses of authoritative servers to IPv6 addresses to initiate communications. Through the mechanism of IPv4-to-IPv6 address translation, these resolvers can operate in an IPv6-only network environment. |