|
|
| |
| Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
|
| draft-ietf-ace-pubsub-profile-09.txt |
| Date: |
04/03/2024 |
| Authors: |
Francesca Palombini, Cigdem Sengul, Marco Tiloca |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (pub/sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. |
| Admin Interface for the OSCORE Group Manager |
|
| draft-ietf-ace-oscore-gm-admin-11.txt |
| Date: |
04/03/2024 |
| Authors: |
Marco Tiloca, Rikard Hoeglund, Peter van der Stok, Francesca Palombini |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession, and server authentication. |
| EAP-based Authentication Service for CoAP |
|
| draft-ietf-ace-wg-coap-eap-10.txt |
| Date: |
04/03/2024 |
| Authors: |
Rafael Marin-Lopez, Dan Garcia-Carrillo |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. |
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) |
|
| draft-ietf-ace-edhoc-oscore-profile-04.txt |
| Date: |
04/03/2024 |
| Authors: |
Goeran Selander, John Mattsson, Marco Tiloca, Rikard Hoeglund |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. |
| Protecting EST Payloads with OSCORE |
|
| draft-ietf-ace-coap-est-oscore-04.txt |
| Date: |
04/03/2024 |
| Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
This document specifies public-key certificate enrollment procedures protected with lightweight application-layer security protocols suitable for Internet of Things (IoT) deployments. The protocols leverage payload formats defined in Enrollment over Secure Transport (EST) and existing IoT standards including the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR), and the CBOR Object Signing and Encryption (COSE) format. |
| Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework |
|
|
This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the Authorization Server can use for uploading an access token to a Resource Server on behalf of the Client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the Authorization Server. Third, it amends two of the requirements on profiles of the framework. Finally, it deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads. For such error responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles of ACE defined in RFC 9202, RFC 9203, and RFC 9431. |
| The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
|
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a Client and one or multiple Resource Servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 Access Token to the public key of the Client associated with the private key used by that Client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client's public key. Also, it provides proof of the Client's membership to the OSCORE group by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s) to verify the Client's membership upon receiving a message protected with Group OSCORE from the Client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. |
| BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
|
| draft-ietf-anima-brski-prm-12.txt |
| Date: |
04/03/2024 |
| Authors: |
Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson |
| Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. The approach defined here is agnostic to the enrollment protocol that connects the domain registrar to the domain CA. |
| A Voucher Artifact for Bootstrapping Protocols |
|
| draft-ietf-anima-rfc8366bis-11.txt |
| Date: |
04/03/2024 |
| Authors: |
Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma |
| Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. |
| Video Frame Marking RTP Header Extension |
|
|
This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec- specific information. |
| RTP over QUIC (RoQ) |
|
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). It also discusses how to leverage state from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets and how to implement congestion control and rate adaptation without relying on RTCP feedback. |
| EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding |
|
|
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. |
| EVPN Port-Active Redundancy Mode |
|
| draft-ietf-bess-evpn-mh-pa-10.txt |
| Date: |
04/03/2024 |
| Authors: |
Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan |
| Working Group: |
BGP Enabled ServiceS (bess) |
|
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability while providing different modes of sharing/balancing of traffic. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document expands on existing redundancy mechanisms supported by EVPN and introduces a new Port- Active redundancy mode. |
| EVPN Support for L3 Fast Convergence and Aliasing/Backup Path |
|
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. |
| BIER Prefix Redistribute |
|
|
This document defines a BIER proxy function to support a single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| Multiple Loss Ratio Search |
|
|
This document proposes extensions to [RFC2544] throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). MLRsearch aims to minimize search duration, support multiple loss ratio searches, and enhance result repeatability and comparability. The primary reason for extending [RFC2544] is to address the challenges and requirements presented by the evaluation and testing of software-based networking systems' data planes. To give users more freedom, MLRsearch provides additional configuration options such as allowing multiple shorter trials per load instead of one large trial, tolerating a certain percentage of trial results with higher loss, and supporting the search for multiple goals with varying loss ratios. |
| A YANG Data Model for Network Tester Management |
|
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. |
| BPF Instruction Set Architecture (ISA) |
|
|
This document specifies the BPF instruction set architecture (ISA). |
| JSContact: A JSON representation of contact data |
|
|
This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. |
| JSContact: Converting from and to vCard |
|
|
This document defines how to convert contact information between the JSContact and vCard data formats. To achieve this, it updates RFC I- D.ietf-calext-jscontact (JSContact) by registering new JSContact properties. Similarly, it updates RFC 6350 (vCard) by registering new vCard properties and parameters. |
| vCard Format Extension for JSContact |
|
|
This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates RFC 6350 (vCard). |
| CDDL Module Structure |
|
| draft-ietf-cbor-cddl-modules-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Carsten Bormann, Brendan Moran |
| Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. |
| A YANG Data Model for Optical Impairment-aware Topology |
|
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks. |
| A YANG Data Model for Layer 0 Types |
|
| draft-ietf-ccamp-rfc9093-bis-09.txt |
| Date: |
04/03/2024 |
| Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093. |
| Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
|
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN pre-position metadata or content as well as request that it invalidate or purge metadata or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| CDNI Cache Control Metadata |
|
|
This specification adds to the basic cache control metadata defined in RFC8006, providing content providers and upstream CDNs (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the origin, bypassing caching altogether, or altering cache keys with dynamically generated values. |
| Implementation Guidance for the PKCS #1 RSA Cryptography Specification |
|
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. |
| CoAP Management Interface (CORECONF) |
|
| draft-ietf-core-comi-17.txt |
| Date: |
04/03/2024 |
| Authors: |
Michel Veillette, Peter van der Stok, Alexander Pelov, Andy Bierman, Carsten Bormann |
| Working Group: |
Constrained RESTful Environments (core) |
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. |
| Group Object Security for Constrained RESTful Environments (Group OSCORE) |
|
| draft-ietf-core-oscore-groupcomm-21.txt |
| Date: |
04/03/2024 |
| Authors: |
Marco Tiloca, Goeran Selander, Francesca Palombini, John Mattsson, Rikard Hoeglund |
| Working Group: |
Constrained RESTful Environments (core) |
|
This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. |
| The Constrained RESTful Application Language (CoRAL) |
|
| draft-ietf-core-coral-06.txt |
| Date: |
04/03/2024 |
| Authors: |
Christian Amsuess, Thomas Fossati |
| Working Group: |
Constrained RESTful Environments (core) |
|
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. |
| Observe Notifications as CoAP Multicast Responses |
|
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. |
| Key Update for OSCORE (KUDOS) |
|
|
This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. |
| DNS over CoAP (DoC) |
|
| draft-ietf-core-dns-over-coap-06.txt |
| Date: |
04/03/2024 |
| Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| OSCORE-capable Proxies |
|
|
Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. |
| Proxy Operations for CoAP Group Communication |
|
|
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. |
| CBOR Encoded X.509 Certificates (C509 Certificates) |
|
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. |
| Reliable and Available Wireless Architecture |
|
|
Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity across any combination of wired and wireless network segments. The RAW Architecture extends the DetNet Architecture and other standard IETF concepts and mechanisms to adapt to the specific challenges of the wireless medium, in particular intermittently lossy connectivity. This document defines a network control loop that optimizes the use of constrained spectrum and energy while maintaining the expected connectivity properties, typically reliability and latency. The loop involves DetNet Operational Plane functions, with a new recovery Function and a new Point of Local Repair operation, that dynamically selects the DetNet path(s) for the future packets to route around local degradations and failures. |
| DNS Error Reporting |
|
|
DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in [RFC8914]. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME, thus the very act of sending the query is to report the error. |
| Compact Denial of Existence in DNSSEC |
|
|
This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. 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/shuque/id-dnssec-compact-lies. |
| Generalized DNS Notifications |
|
|
This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new NOTIFY record type. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. |
| In the DNS,QDCOUNT is (usually) One |
|
|
This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. |
| DNSSEC Trust Anchor Publication for the Root Zone |
|
| draft-ietf-dnsop-rfc7958bis-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Joe Abley, Jakob Schlyter, Guillaume Bailey, Paul Hoffman |
| Working Group: |
Domain Name System Operations (dnsop) |
|
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. |
| Service Registration Protocol for DNS-Based Service Discovery |
|
| draft-ietf-dnssd-srp-25.txt |
| Date: |
04/03/2024 |
| Authors: |
Ted Lemon, Stuart Cheshire |
| Working Group: |
Extensions for Scalable DNS Service Discovery (dnssd) |
|
The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. |
| Advertising Proxy for DNS-SD Service Registration Protocol |
|
|
An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNS-SD Service Registration Protocol (SRP), using multicast DNS. This allows legacy clients to discover services registered with SRP using multicast DNS. |
| Automatic Replication of DNS-SD Service Registration Protocol Zones |
|
|
This document describes a protocol that can be used for ad-hoc replication of a DNS zone by multiple servers where a single primary DNS authoritative server is not available and the use of stable storage is not desirable. |
| api-catalog: a well-known URI and link relation to help discovery of APIs |
|
|
This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of the APIs published by a given organisation or individual. |
| Resumable Uploads for HTTP |
|
|
HTTP clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. Prior to interruption, part of a representation may have been exchanged. To complete the data transfer of the entire representation, it is often desirable to issue subsequent requests that transfer only the remainder of the representation. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios |
|
|
The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes a solution to address the RT-Constrain issue in hierarchical RR scenarios. |
| BGP Extended Community for Identifying the Target Nodes |
|
|
BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose. |
| BGP Flowspec for IETF Network Slice Traffic Steering |
|
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic flow specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be preformed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). |
| Segment Routing Segment Types Extensions for BGP SR Policy |
|
|
This document specifies the signaling of additional Segment Routing Segment Types for BGP SR Policy SAFI. |
| A YANG Data Model for Network Inventory |
|
|
This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models. |
| Key Transparency Architecture |
|
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency (KT) in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply KT to a number of common applications. |
| Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication |
|
|
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey). |
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE |
|
| draft-ietf-lake-authz-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document describes a procedure for authorizing enrollment of new devices using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). The procedure is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) |
|
|
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM Algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM Algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in draft- ietf-lamps-cms-kemri. |
| DLEP Credit-Based Flow Control Messages and Data Items |
|
|
This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that are used to support credit-based flow control. Credit window control is used to regulate when data may be sent to an associated virtual or physical queue. The Data Items are defined in an extensible and reusable fashion. Their use will be mandated in other documents defining specific DLEP extensions. |
| Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure |
|
|
This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, this document discusses those applications that run on devices having different form factors (such as different physical sizes and shapes) and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. This document discusses the expected behavior of XR applications which can be used to manage the traffic. In addition, the document discusses the service requirements of XR applications to be able to run on the network. |
| Media over QUIC Transport |
|
| draft-ietf-moq-transport-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Luke Curley, Kirill Pugin, Suhas Nandakumar, Victor Vasiliev, Ian Swett |
| Working Group: |
Media Over QUIC (moq) |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| Network Digital Twin: Concepts and Reference Architecture |
|
|
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications and realize efficient and cost effective data driven network management, and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses the benefits and key challenges of such technology. |
| Research Challenges in Coupling Artificial Intelligence and Network Management |
|
| draft-irtf-nmrg-ai-challenges-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Jerome Francois, Alexander Clemm, Dimitri Papadimitriou, Stenio Fernandes, Stefan Schneider |
| Working Group: |
Network Management (nmrg) |
|
This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require to couple with Artificial Intelligence (AI) solutions. On the one hand, there are many difficult problems in NM that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that network are operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. |
| Correlation of multiple responses of forked INVITES in Back to Back User Agents |
|
|
This document describe how a correlation of multiple responses of a forked INVITE in Back to Back User Agents can apply. |
| Discovery of OSCORE Groups with the CoRE Resource Directory |
|
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. |
| SRv6 and MPLS interworking |
|
|
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. |
| CoRE Resource Directory Extensions |
|
|
A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. |
| Proxy MAC-IP Advertisement in EVPNs |
|
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. |
| Composite ML-DSA for use in Internet PKI |
|
|
This document defines Post-Quantum / Traditional composite Key Signaturem algorithms suitable for use within X.509, PKIX and CMS protocols. Composite algorithms are provided which combine ML-DSA with RSA, ECDSA, Ed25519, and Ed448. The provided set of composite algorithms should meet most X.509, PKIX, and CMS needs. |
| Destination-IP-Origin-AS Filter for BGP Flow Specification |
|
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. |
| Scalable Approaches on Supporting IOAM in IPv6 |
|
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, and applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
|
|
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. |
| SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
|
|
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS. |
| Interconnection Intents |
|
|
This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. |
| SRv6 In-situ Active Measurement |
|
|
This draft describes an active measurement method for SRv6 which can support segment-by-segment and end-to-end measurement on any SRv6 path using existing protocols such as IOAM. A packet containing an SRH uses a flag bit to indicate the packet is an active probing packet and requires segment-by-segment processing. The measurement information, such as the IOAM header and data, is encapsulated in UDP payload, indicated by a dedicated port number. The probing packet originates from a segment source node, traverses an arbitrary segment path, and terminates at a segment endpoint node, as configured by the segment list in SRH. Each segment node on the path, when detecting the flag, shall parse the UDP header and the payload. In the case of IOAM, the node shall process the IOAM option conforming to the standard procedures defined in the IOAM documents. The method is compatible with some other SRv6 active measurement proposals and support multiple applications. |
| Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option |
|
| draft-tllq-tsr-04.txt |
| Date: |
04/03/2024 |
| Authors: |
Ted Lemon, Liang Qin |
| Working Group: |
Individual Submissions (none) |
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD Advertising Proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. |
| Traffic Mapping YANG model for Traffic Engineering (TE) |
|
|
This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model providers operator a seamless control and management of which traffic to send on the underlying TE resources. |
| Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |
|
|
This document updates requirements on implementations of various Salted Challenge Response Authentication Mechanism (SCRAM) Simple Authentication and Security Layer (SASL) mechanisms based on more modern security practices. |
| EVPN Fast Reroute |
|
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements |
|
|
PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. |
| Everything over CoAP |
|
|
The Constrained Application Protocol (CoAP) has become the base of applications both inside of the constrained devices space it originally aimed for and outside. This document gives an overview of applications that are, can, may, and would better not be implemented on top of CoAP. |
| Signalling CC Parameters for Careful Resume using QUIC |
|
|
This document describes an extension for QUIC. This enables the exchange of Congestion Control (CC) parameters related to the characteristics of the between the sender and the receiver during a connection. These CC parameters allow a receiver to prepare to use additional capacity that is made available when using Careful Resume. It can also allow a receiver to request that previously computed CC parameters, are not used when the receiver has additional information about the current path or traffic that is to be sent. |
| The Architecture of Network-Aware Domain Name System (DNS) |
|
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| SCION Control-Plane PKI |
|
|
This document presents the trust concept and design of the SCION _control-plane Public Key Infrastructure (PKI)_, SCION's public key infrastructure model. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture. The control-plane PKI, or short CP-PKI, handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's control plane to authenticate and verify path information, and builds the basis for SCION's special trust model based on so-called Isolation Domains. This document first introduces the trust model behind the SCION's control-plane PKI, as well as clarifications to the concepts used in it. This is followed by specifications of the different types of certificates and the Trust Root Configuration. The document then specifies how to deploy the whole infrastructure. |
| SAV-based Anti-DDoS Architecture |
|
|
Existing SAV schemes can not effectively defend against IP Spoofing DDoS under incremental deployment. This document proposes SAV-D, a savnet based distributed defense architecture to enhance SAV's defense. The main idea of SAV-D is to collect and aggregate more threat data from existing SAV devices and then distribute crucial knowledge to widespread devices, thus significantly expanding defense across the entire network. |
| Additional addresses for QUIC |
|
|
This document specifies a QUIC frame enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. |
| The JSON format for vCon - Conversation Data Container |
|
| draft-petrie-vcon-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Daniel Petrie, Thomas McCarthy-Howe |
| Working Group: |
Individual Submissions (none) |
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) |
| Encapsulation of BFD for SRv6 Policy |
|
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. |
| An EAT-based Key Attestation Token |
|
| draft-bft-rats-kat-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Mathias Brossard, Thomas Fossati, Hannes Tschofenig |
| Working Group: |
Individual Submissions (none) |
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. |
| Requirements and Design for Interfaces of Network Digital Twin |
|
|
The interfaces of Digital Twin Network can be divided as twin network southbound interface, internal interface and northbound interface. In order to build a digital twin network and realize its many advantages, different interfaces should be able to meet different requirements. And this memo introduces the requirements and design about interfaces of the Digital Twin Network. |
| Inter-domain Source Address Validation (SAVNET) Architecture |
|
|
This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. |
| EVPN Multicast Forwarding for EVPN to EVPN Gateways |
|
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. |
| Reliability Considerations of Path-Aware Semantic Addressing |
|
|
Path-Aware Semantic Address (PASA), proposes to algorithmically assign addresses to nodes in a 6lo environment so to achieve stateless forwarding, hence, allowing to avoid using a routing protocol. PASA is more suitable for stable and static wireline connectivity, in order to avoid renumbering due to topology changes. Even in such kind of scenarios, reliability remains a concern. This memo tackles specifically reliability in PASA deployments, analyzing possible broad solution categories to solve the issue. |
| Handling Encrypted DNS Server Redirection |
|
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. |
| Flag-based MPLS On Path Telemetry Network Actions |
|
|
This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks. |
| Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
|
|
This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol |
|
|
This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. |
| Timeslot Queueing and Forwarding Mechanism |
|
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme in IP/MPLS networks, which we call timeslot queueing and forwarding (TQF) mechanism. It aims to bring timeslot resources to layer-3, to make it easier for the control plane to calculate the delay performance based on the timeslot resources, and also make it easier for the data plane to create more flexible timeslot mapping. The functions of TQF can better meet large scaling requirements. |
| the extensions of BGP-LS to carry security capabilities |
|
|
As users' traffic faces more unpredictable attacks during transmission, there are more and more end-users now need high security data transmission guarantee, they need ISPs to provide security protection capabilities on the data forwarding path. Therefore, ISPs need to have real-time awareness of the security capabilities available in the network, then form a security capability map, finally provide security protection for users at the routing level. The goal of this draft is to collect the security capabilities of nodes, which will be one of the factors to form the routing topology, and use the routing programming capabilities to form a secure routing path. The security capability includes healthy information(such as the device software is up-to-date), security service information, device information(such as the manufacturer information of the equipment). The BGP-LS protocol is extended to carry the security capabilities of the node. The controller collects topology information, forms a topology path with security capabilities according to security requirements, and supports SRv6 path sending to execute node forwarding through programming. |
| Simplified MVPN for BIER and IR |
|
|
Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution. |
| EVPN Inter-Domain Option-B Solution |
|
|
An EVPN Inter-Domain interconnect solution is required if two or more sites of the same Ethernet Virtual Private Network (EVPN) are attached to different IGP domains or Autonomous Systems (AS), and they need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for such EVPN connectivity. While multiple documents refer to this type of interconnect solution and specify different aspects of it, there is no document that summarizes the impact of the Inter-Domain Option-B connectivity in the EVPN procedures. This document does not specify new procedures but analyses the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the described issues. Those solutions are based on either other specifications or based on local implementations that do not modify the end-to-end EVPN control plane. |
| Merkle Tree Certificates for TLS |
|
|
This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post- quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. |
| A YANG Data Model for Optical Resource Performance Monitoring |
|
|
This document defines a YANG data model for performance Monitoring in optical networks which provides the functionalities of performance monitoring task management, TCA (Threshold Crossing Alert) configuration and current or historic performance data retrieval. This data model should be used in the northbound of PNC. |
| BMP Loc-RIB: Peer address |
|
|
BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. |
| Structured Connection ID Carrying Metadata |
|
|
This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization. |
| Realization of Composite IETF Network Slices |
|
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC XXXX describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC XXXX. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. |
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance |
|
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios, for end-to-end customer L2VPN or L3VPN connectivity services setup over underlying transport optical paths, with specific Service Level Agreement (SLA) requirements. EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. |
| Low Overhead Media Container |
|
| draft-mzanaty-moq-loc-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Mo Zanaty, Suhas Nandakumar, Peter Thatcher |
| Working Group: |
Individual Submissions (none) |
|
This specification describes a media container format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC transport (MOQ), with the goal of it being a low-overhead format. It also defines the LOC Streaming Format for the MOQ Common Catalog format for publishers to annouce and describe their LOC tracks and for subscribers to consume them. |
| Content Delivery Network Interconnection (CDNI) Named Footprints |
|
|
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 extends the Footprint & Capabilities Advertisement Interface (FCI) defined in RFC8008, to allow advertising of named footprint objects, that can be referenced in a consistent manner from Metadata Interface (MI), also defined in RFC8006, as well as from the FCI itself as well as additional interfaces in the Open Caching architecture. This document also supplements the CDNI Metadata Footprint Types defined in RFC8006 and modifies the CDNI operation as described in RFC7336. |
| Green Challenges in Computing-Aware Traffic Steering (CATS) |
|
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. |
| Green Networking Metrics |
|
| draft-cx-opsawg-green-metrics-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Alexander Clemm, Lijun Dong, Greg Mirsky, Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini, Eve Schooler, Ali Rezaki, Carlos Pignataro |
| Working Group: |
Individual Submissions (none) |
|
This document explains the need for network instrumentation that allows to assess a number of sustainability-related attributes such as power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's "greenness" accordingly. |
| RIFT extensions for SRv6 |
|
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topologicalelements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the RIFT extensions required to support Segment Routing over the IPv6 data plane (SRv6). |
| PIM Flooding Mechanism Enhancements |
|
|
PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows Last Hop Routers to learn about new sources using PFM messages, without the need of initial data registers, RPs or shared trees. This document defines a methodology that enhances forwarding efficiency in PFM deployments. This enhancement can avoid extra processing at PIM routers when PFM messages are forwarded. |
| SCION Control Plane |
|
|
This document describes the control plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to SCION- capable endpoints. In fact, endpoints can choose between multiple path options, enabling the optimization of network paths. The SCION control plane is responsible for discovering these paths and making them available to the endpoints. The main goal of SCION's control plane is to create and manage path segments, which can then be combined into forwarding paths to transmit packets in the data plane. This document first discusses how path exploration is realized through beaconing and how path segments are created and registered. Each SCION autonomous system (AS) can register segments according to its own policy - it is free to specify which path properties and algorithm(s) to use in the selection procedure. The document then describes the path lookup process, where endpoints obtain path segments - a fundamental building block for the construction of end-to-end paths. |
| PIM Flooding Mechanism and Source Discovery Sub-TLV |
|
|
PIM Flooding Mechanism and Source Discovery (RFC 8364) allows for announcement of active sources, but it does not allow for providing additional information about the flow. This document defines a new TLV for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. This document defines a Sub-TLV for flow data rate. |
| Bundle Protocol Yang Model |
|
|
This document describes the Yang model for the Bundle protocol. |
| Transmission of IPv6 Packets over Short-Range Optical Wireless Communications |
|
| draft-choi-6lo-owc-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Younghwan Choi, Cheol-min Kim, Carles Gomez |
| Working Group: |
Individual Submissions (none) |
|
IEEE 802.15.7, "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both line-of-sight (LOS) and non-line-of-sight (NLOS) communications. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
| Additional MLS Credentials |
|
|
This specification defines two new kinds of credentials for use within the Message Layer Security (MLS) credential framework: UserInfo Verifiable Credentials and multi-credentials. UserInfo Verifiable Credentials allow clients to present credentials that associate OpenID Connect attributes to a signature key pair held by the client. Multi-credentials allow clients to present authenticated attributes from multiple sources, or to present credentials in different formats to support groups with heterogeneous credential support. |
| Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP) |
|
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP). DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions. |
| Routing in Dragonfly+ Topologies |
|
|
This document provides an overview of Dragonfly+ network topology and describes routing implementation for IP networks with Dragonfly+ topology with support for non-minimal routing.t |
| Packed CBOR: Table set up by reference |
|
|
Packed CBOR is a compression mechanism for Concise Binary Object Representation (CBOR) that can be used without a decompression step. This document introduces a means for setting up its tables by means of dereferencable identifiers, and introduces a pattern of using it without sending long identifiers. |
| MIMI Discovery Requirements and Considerations |
|
|
This document defines requirements and use cases for the discovery problem in the More Instant Messaging Interoperability (MIMI) working group. The discovery problem refers to the process by which a message sender can identify the provider(s) associated with a desired messaging recipient, who is normally identified by an email address or phone number. |
| Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions |
|
|
Deep space communications involve long delays (e.g., Earth to Mars is 4-20 minutes) and intermittent communications, because of orbital dynamics. Up to now, communications have been done on a layer-2 point to point basis, with sometimes the use of relays, therefore no layer-3 networking was possible. RFC4838 reports an assessment done around 25 years ago concluding that the IP protocol stack was not suitable for deep space networking. This result lead to the definition of a new protocol stack based on a store-and-forward paradigm implemented in the Bundle Protocol(BP). More recently, space agencies are planning to deploy IP networks on celestial bodies, such as Moon or Mars, ground, and vicinity. This document revisits the initial assessment of not using IP and provides solution paths to use the IP protocol stack, from IP forwarding to transport to applications to network management, in deep space communications. |
| JMAP extension for S/MIME signing and encryption |
|
|
This document specifies an extension to JMAP for sending S/MIME signed and/or S/MIME encrypted messages, as well as automatic decryption of received S/MIME messages. [[This version presents an alternative syntax to revision 04 of https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender- extensions/]] |
| SCION Data Plane |
|
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). One of the basic characteristics of SCION is that it gives path control to endpoints. The SCION control plane is responsible for discovering these paths and making them available as path segments to the endpoints. The responsibility of the *SCION data plane* is to combine the path segments into end-to-end paths, and forward data between endpoints according to the specified path. The SCION data plane fundamentally differs from today's IP-based data plane in that it is _path-aware_: In SCION, interdomain forwarding directives are embedded in the packet header. This document first provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers - these are described, too. The document then shows the life cycle of a SCION packet while traversing the SCION Internet. This is followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. SCION also includes its own protocol to communicate failures to endpoints, the SCION Control Message Protocol (SCMP). This protocol will be described in a separate document, which will follow later. |
| OpenPGP HTTP Keyserver Protocol |
|
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| Certificate Management over CMS (CMC) |
|
|
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: |
| Certificate Management over CMS (CMC): Transport Protocols |
|
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFCs 5273 and 6402. |
| Certificate Management Messages over CMS (CMC): Compliance Requirements |
|
|
This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. This document obsoletes RFCs 5274 and 6402. |
| The Mastic VDAF |
|
| draft-mouris-cfrg-mastic-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Hannah Davis, Dimitris Mouris, Christopher Patton, Pratik Sarkar, Nektarios Tsoutsos |
| Working Group: |
Individual Submissions (none) |
|
This document describes Mastic, a two-party VDAF for the following aggregation task: each client holds a string, and the collector wishes to count how many of these strings begin with a given prefix. Such a VDAF can be used to solve the private heavy hitters problem, where the goal is to compute the subset of the strings that occur most frequently without learning which client holds which string. This document also describes different modes of operation for Mastic that support additional use cases and admit various performance and security trade-offs. |
| CDNI Metadata Expression Language |
|
|
This document specifies the syntax and provides usage examples for an expression language to be used within Streaming Video Technology Alliance (SVTA)/Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| CDNI Processing Stages Metadata |
|
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| TLS Trust Expressions |
|
|
This document defines TLS trust expressions, a mechanism for relying parties to succinctly convey trusted certification authorities to subscribers by referencing named and versioned trust stores. It also defines supporting mechanisms for subscribers to evaluate these trust expressions, and select one of several available certification paths to present. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements. |
| Recommendations for using Multiple IP Addresses in Benchmarking Tests |
|
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers, but it kept the usage of a single source and destination IP address pair when a single destination network is used. This limitation may cause an issue when the device under test uses Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two types of implementations: the first one only includes the IP addresses, whereas the second one also includes the port numbers into the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation, because in this case, the traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did it with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. |
| Path Computation and Control Extention Requirements for Fine-Granularity Transport Network |
|
|
This document focuses on the requirements for path computation and control of the fine-granularity transport network. It provides the general context of the use cases of path computation and the considerations on the requirements of PCE extension in such fine- granularity transport network. |
| A Multiplane Architecture Proposal for the Quantum Internet |
|
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. |
| Extended information of Semantic Definition Format (SDF) for Digital Twin |
|
|
An SDF specification can describe the definition of a Things, i.e., physical objects and their associated interactions and express the various information that be exchanged for the interactions. Therefore, the SDF format can be used to define the behaviour of an object and its associated data model and interaction model in a digital twin system that has an object as a component. In a digital twin system, interactions between physical and virtual objects, as well as interactions of objects existing in the different digital twin systems, are performed over a network, which is important to provide location information of objects during interactions. This document specifies the extension information of SDF to represent the location information of an objects. |
| the architecture for secure routing |
|
|
Some users need to choose nodes that meet security requirements to form secure routing and ensure that traffic can defend against dynamic attacks during path forwarding. In this architecture, there are four roles defined: attester, authorizer, controller and secfunction, the interaction of these four roles can achieve the selection of secure routing and security services. The purpose of this architecture is to secure the routing, including node static security assessment, dynamic security defense, and routing path and security service consistency validation. |
| Automating DNS Delegation Management via DDNS |
|
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastropic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via- ddns (https://github.com/johanix/draft-johani-dnsop-delegation-mgmt- via-ddns). The most recent working version of the document, open issues, etc, should all be available there. The author (gratefully) accept pull requests. |
| Opportunistic TCP-AO with TLS |
|
| draft-piraux-tcp-ao-tls-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Maxime Piraux, Olivier Bonaventure, Thomas Wirtgen |
| Working Group: |
Individual Submissions (none) |
|
This document specifies an opportunistic mode for TCP-AO. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. |
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
|
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. This document defines a number of means to coordinate the use and discovery of EDHOC application profiles. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, it defines a well-known EDHOC application profile. |
| 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 |
| Application of Explicit Measurement Techniques for QUIC Troubleshooting |
|
| draft-mdt-quic-explicit-measurements-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Alexandre Ferrieux, Igor Lubashev, Giuseppe Fioccola, Isabelle Hamchaoui, Massimo Nilo, Fabio Bulgarella, Mauro Cociglio |
| Working Group: |
Individual Submissions (none) |
|
This document defines an extension to the QUIC transport protocol to allow endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). |
| Happy Eyeballs Version 3: Better Connectivity Using Concurrency |
|
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. |
| Post-quantum cryptography migration use cases |
|
|
This document is meant to be continuously updated, to incorporate emerging Post-Quantum Cryptography (PQC) migration use cases, with a focus on the migration from traditional signature algorithms (e.g., RSA, DSA, ECDSA) to PQC signature algorithms (e.g., LMS, XMSS, ML- DSA, SLH-DSA). This document aims at categorizing real-world scenarios based on a set of distinctive features. The primary goal is to facilitate discussions on migration strategies by offering a systematic taxonomy and a shared understanding among stakeholders. |
| Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS) |
|
|
BIER provides stateless multicast in BIER domains using bitstrings to indicate receivers. BIER-TE extends BIER with tree engineering capabilities. Both suffer from scalability problems in large networks as bitstrings are of limited size so the BIER domains need to be subdivided using set identifiers so that possibly many packets need to be sent to reach all receivers of a multicast group within a subdomain. This problem can be mitigated by encoding explicit multicast trees in packet headers with bitstrings that have only node-local significance. A drawback of this method is that any hop on the path needs to be encoded so that long paths consume lots of header space. This document presents the idea of Segment Routed Recursive Tree Structures (RTS), a unifying approach in which a packet header representing a multicast distribution tree is constructed from a tree structure of vertices ("so called Recursive Units") that support replication to their next-hop neighbors either via local bitstrings or via sequence of next-hop neighbor identifiers called SIDs. RTS, like RBS is intended to expand the applicability of deployment for stateless multicast replication beyond what BIER and BIER-TE support and expect: larger networks, less operational complexity, and utilization of more modern forwarding planes as those expected to be possible when BIER was designed (ca. 2010). This document only specifies the forwarding plane but discusses possible architectural options, which are primarily determined through the future definition/mapping to encapsulation headers and controller-plane functions. |
| EVPN L3-Optimized IRB |
|
|
Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) provides dynamic and efficient intra and inter-subnet connectivity among Tenant Systems and end devices while maintaining very flexible multihoming capabilities. This document describes how EVPN-IRB can be optimized for IP hosts and devices such that PE devices only maintain MAC addresses for locally-connected IP hosts,thus improving MAC scalability of customer bridges and PE devices significantly. This document describes how such optimization is acheived while still supporting host moblity which is one of the fundamental features in EVPN and EVPN-IRB. With such optimization PE devices perform routing for both intra and inter-subnet traffic which results in some some caveats that operators and service providers need to be fully aware of. |
| CDNI Logging Extensions |
|
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. |
| Secure Telephone Identity for Message Layer Security |
|
|
This document specifies Message Layer Security (MLS) Credential Types for use with Secure Telephone Identity Revisited (STIR), one for STIR certificates and another for the Personal Assertion Token (PASSporT). |
| Large Record Sizes for TLS and DTLS |
|
|
RFC 8449 defines a record size limit extension for TLS and DTLS allowing endpoints to negotiate a record size limit smaller than the protocol-defined maximum record size, which is around 2^14 bytes. This document specifies a TLS flag extension to be used in combination with the record size limit extension allowing endpoints to use a record size limit larger than the protocol-defined maximum record size, but not more than about 2^16 bytes. |
| Centralized Anycast Gateway in Ethernet VPN(EVPN) |
|
|
EVPN Integrated Routing and Bridging (IRB) fabrics provide a flexible and extensible method for Layer-2 and Layer-3 overlay network connectivity. [EVPN-IRB] defines operation for symmetric and asymmetric EVPN IRB using distributed anycast gateway architecture (DAG). In a DAG architecture, both bridging and first-hop routing functions for overlay subnets are located on leaf PEs, with first-hop routing provided by a distributed anycast gateway provisioned across the leaf PEs. This document describes an architecture and operation for EVPN Centralized Anycast Gateway (CAG), which allows the first- hop routing function for overlay subnets to be centralized on designated IRB GWs while the bridging function is still located on the leaf PEs. The documents also covers trade-offs of deploying a CAG as compared with DAG. It further describes operation for inter- op between CAG and DAG based EVPN-IRB network overlays. |
| Joint Exposure of Network and Compute Information for Infrastructure-Aware Service Deployment |
|
|
Service providers are starting to deploy computing capabilities across the network for hosting applications such as distributed AI workloads, AR/VR, vehicle networks, and IoT, among others. In this network-compute environment, knowing information about the availability and state of the underlying communication and compute resources is necessary to determine both the proper deployment location of the applications and the most suitable servers on which to run them. Further, this information is used by numerous use cases with different interpretations. This document proposes an initial approach towards a common understanding and exposure scheme for metrics reflecting compute and communication capabilities. |
| YANG Full Embed |
|
|
YANG lacks re-usability of models defined outside of the grouping and augmentation mechanisms. For instance, it is almost impossible to reuse a model defined for a device in the context of the network, i.e by encapsulating it in a list indexed by device IDs. [RFC8528] defines the YANG mount mechanism, partially solving the problem by allowing to mount an arbitrary set of schemas at an arbitrary point. However, YANG mount is only focusing on deploy or runtime. This document aims to provide the same mechanism at design time. |
| Augmented-by Addition into the IETF-YANG-Library |
|
|
This document augments the ietf-yang-library in [RFC8525] to provide the augmented-by list. It facilitates the process of obtaining the entire dependencies of YANG model, by directly querying the server's YANG module. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| Basic Requirements for IPv6 Customer Edge Routers |
|
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. |
| Intent Translation Engine for Intent-Based Networking |
|
| draft-pedro-ite-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Pedro Martinez-Julia, Jaehoon Jeong |
| Working Group: |
Individual Submissions (none) |
|
This document specifies the schemas and models required to realize the data formats and interfaces for Intent-Based Networking (IBN). They are needed to enable the composition of services to build a translation engine for IBN-based network management. This intent translation engine (called an intent translator) is an essential function for network intents to be enforced into a target network for the configuration and management of the network and its security. |
| Characterization and Benchmarking Methodology for Power in Networking Devices |
|
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices and under different network configurations and conditions. |
| A YANG Data Model for the Alternate Marking Method |
|
| draft-ydt-ippm-alt-mark-yang-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Thomas Graf, Minxue Wang, Giuseppe Fioccola, Tianran Zhou, Xiao Min, Guo Jun, Massimo Nilo, Liuyan Han |
| Working Group: |
Individual Submissions (none) |
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. |
| A Reference Implementation of Ascertaining RPKI Signed Objects to be Validated in Incremental Updates |
|
|
This document describes a reference implementation of how an RP ascertains which RPKI signed objects that need to be validated during a transaction of RPKI incremental update from the perspective of this RP. |
| A YANG Data Model for Network Element Threat Surface Management |
|
|
This document defines a base YANG data model for network element threat surface management that is application- and technology- agnostic. |
| Hierarchical methods of computing metrics distribution |
|
|
This document analyzes the necessarity of setting hierarchical methods of computing metrics distribution. Besides, we propose the workflow of hierarchical metric distribution for different CATS frameworks. |
| Alternate Marking Deployment Status and Considerations |
|
|
Operators have started the deployment of Alternate Marking in their networks for different scenarios. This document introduces several deployment cases of Alternate Marking in operator networks. Some considerations about the Alternate Marking deployments are also collected. |
| Application-aware Networking (APN) Framework |
|
| draft-li-rtgwg-apn-framework-00.txt |
| Date: |
04/03/2024 |
| Authors: |
Zhenbin Li, Shuping Peng, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra |
| Working Group: |
Individual Submissions (none) |
|
A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. |
| A YANG Model for Application-aware Networking (APN) |
|
|
Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute (incl. APN ID and/or APN Parameters) to enable fine grained service provisioning. This document defines a YANG module for APN. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| Dissemination of BGP Flow Specification Rules for APN |
|
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute including APN ID and/or APN Parameters. The dynamic Flow Spec mechanism for APN is designed for the new applications of traffic filtering in an APN domain as well as the traffic control and actions at the policy enforcement points in this domain. These applications require coordination among the ASes within a service provider. This document specifies a new BGP Flow Spec Component Type in order to support APN traffic filtering. The match field is the APN ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsulation when matched to the corresponding Flow Spec rules. |
| Benchmarking Methodology for Segment Routing |
|
| draft-vfv-bmwg-sr-bench-meth-00.txt |
| Date: |
04/03/2024 |
| Authors: |
Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene |
| Working Group: |
Individual Submissions (none) |
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). It builds upon RFC 2544, RFC 5180, RFC 5695 and RFC 8402. |
| SRv6 Service Benchmarking Guideline |
|
|
This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. |
| Application-aware IPv6 Networking (APN6) Encapsulation |
|
|
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the APN header and its encapsulation in the IPv6 data plane. |
| Post-Quantum Cryptography enhancement in EAP-AKA prime |
|
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [I-D.ietf-emu-aka-pfs], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS making it quantum-safe. |
| IPv6-Mostly Networks: Deployment and Operations Considerations |
|
|
This document discusses an deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). |
| Applicability of GMPLS for fine grain Optical Transport Network |
|
|
ITU-T Recommendation G.709/Y.1331 Edition 6.5 [G709-E6.5] introduced new fine grain OTN (fgOTN) for the efficient transmission of sub-1G client signals. This document reviews the fgOTN control plane requirements, examines the applicability of using existing GMPLS control plane for fgOTN, and provides the standard gap analysis and considerations on GMPLS extensions. |
| EAP Multiple Pre-Shared Keys (EAP-MPSK) Method |
|
|
This document defines an Extensible Authentication Protocol (EAP) method for supporting the negotiation of a PSK among multiple PSKs. |
| BGP Link-State Extensions for Source Address Validation Networks (SAVNET) |
|
|
BGP Link-state uses the BGP protocol to collect and report network topology to the network controller. This document defines a new type of BGP-LS NLRI for reporting source address validation-related information to the controller. The reported information can be used to generate SAV rules centrally. |
| Operations,Administration and Maintenance (OAM) for Computing-Aware Traffic Steering |
|
| draft-fu-cats-oam-fw-00.txt |
| Date: |
04/03/2024 |
| Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Cheng Huang, Liwei Ma, Wei Duan |
| Working Group: |
Individual Submissions (none) |
|
This document describes an OAM framework for Computing-Aware Traffic Steering (CATS). The proposed OAM framework enables the fault and the performance management of end-to-end connections from clients to networks and finally to computing instances. In the following sections, the major components of the framework, the functionalities, and the deployment considerations are elaborated in detail. |
| Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
|
| draft-fu-cats-muti-dp-solution-00.txt |
| Date: |
04/03/2024 |
| Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| Working Group: |
Individual Submissions (none) |
|
This document presents an overall framework for the data plane of Computing-Aware Traffic Steering (CATS). In particular, it illustrates several optional and possible data plane solutions, compares their key features and main differences, and analyzes their corresponding applicable scenarios. |
| Computing Aware Traffic Steering Consideration for Mobile User Plane Architecture |
|
|
The document [I-D.draft-mhkk-dmm-srv6mup-architecture] describes the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The proposed architecture converts the user mobility session information from the control plane entity to an optimal IPv6 dataplane routing information. However, when anycast address is used for service in data network (DN), this solution can be enhanced to dynamically set up the dataplane to the optimal service instance. This document discusses a solution to integrate computing-aware traffic steering capabilities to the mentioned MUP architecture. The target applied use-case is the anycast IP services scenario, where different instances that share the same anycast address of the service can serve the user request. For each session request, based on the up-to-date collected computing and network information, the MUP controller can convert the session information to the dataplane routing information to the optimal service instance. |
| Signaling Use Cases for Traffic Differentiation |
|
|
Host-to-network signaling can improve the user experience by informing the network which flows are more important and which packets within a flow are more important. The differentiated service may be provided at the network (e.g., packet prioritization), the sender (e.g., adaptive transmission), or through cooperation of both the sender and the network. This document outlines use-cases that highlight the need for a new signaling protocol from the receiver to its network elements which enables different traffic treatment. |
| SAVNET Use Cases |
|
| draft-ys-savnet-use-cases-00.txt |
| Date: |
04/03/2024 |
| Authors: |
1211176911910469110103, Xueyan Song, Changwang Lin, Nan Geng |
| Working Group: |
Individual Submissions (none) |
|
This document introduces the use case for Source Address Validation (SAV) applied in intra-domain and inter-domain telecommunication networks. It describes the typical routing implements and possible improvements for SAV in the use cases. |
| Best practices for traffic steering to SRv6 |
|
|
This document primarily describes the traffic steering towards SRv6- BE and SRv6-TE respectively, providing an overview of the main traffic steering methods for these two approaches. Furthermore, it discusses the recommended traffic steering methods for various typical scenarios. |
| Intra-domain SAV Support via BGP |
|
|
This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAVNET table entries based on intra-domain next hop SAVNET rules. The generation of intra- domain next hop SAVNET rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAVNET rules to generate the SAVNET rule table for source prefixes. |
| BGP Flowspec for Computing-Aware Traffic Steering |
|
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework, This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. |
| Distribute Service Metric By BGP |
|
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the server site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems |
|
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system like Kubernetes and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. |
| Scenarios and Potential Future Work of Enterprise Network Policies |
|
|
This document describes several typical scenarios of utilizing network policies against enterprise networks, and discusses some existing work and the limitations. Lastly, this document proposes several aspects of potential future work that might led to a formation of policy plane for enterprise networks. |
| Non-source-routed Multicast in SR Networks |
|
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane. |
| Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP |
|
| draft-wang-idr-bgp-nof-nlri-00.txt |
| Date: |
04/03/2024 |
| Authors: |
Ruixue Wang, Changwang Lin, Mengxiao Chen, Fengwei Qin, Qi Zhang, wangwenxuan |
| Working Group: |
Individual Submissions (none) |
|
This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. |
| Structured vacation notices |
|
|
This document describes a machine-readable format for vacation notice messages. It is supposed to be used in conjuction with conventional, human-readable vacation notices. |
| CDNI Source Access Control Metadata |
|
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| CDNI Delivery Metadata |
|
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, Open Caching request delegation behavior for Open Caching node selection, and request routing modes of traffic delegation. |
| CDNI Private Features Metadata |
|
|
This specification defines a mechanism for downstream content delivery networks (dCDNs) to define private extensions to the metadata model that are mutually agreed upon between participating upstream content delivery networks (uCDNs) and dCDNs. |
| Compute-Aware Traffic Steering for Midhaul Networks |
|
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. |
| 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. |
| IPv6 Hop-by-hop and Destination Options Forwarding In Routers |
|
|
It has become accepted that packets containing IPv6 Extension Headers, especially Hop-by-hop Options, are frequently dropped on the Internet. However, the question still remains as to why they get dropped and what type of devices may be dropping them. This document describes research conducted to isolate routers in a simple topology, with minimal configuration, and shows that router implementations alone are likely not the cause of packets containing IPv6 Extension Headers being dropped on the Internet. |
| Remote attestation over EDHOC |
|
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. |
| An Identitifier Proof-of-Possession Mechanism |
|
|
This document specifies a means for a third-party service to prove and attest the association of a communications platform with a particular user's telephone number. This capability supports secure enrollment for users of messaging platforms or similar real-time communication applications, for cases where users assert telephone numbers as communication identifiers, and interoperating platforms need to verify that identifiers are being properly attested. This general approach can potentially work with other forms of Service Independent Identifiers (SIIs) in the More Instant Messaging Interoperability (MIMI) framework. |
| A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology |
|
|
This document defines a YANG data model for representing an abstracted view of a network topology that contains Intermediate System to Intermediate System (IS-IS). This document augments the 'ietf-network' data model by adding IS-IS concepts and explains how the data model can be used to represent the IS-IS topology. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| Consideration for IP-Based TVR (Time-Variant Routing) |
|
|
Satellite network are one of the TVR's use case. This document makes some considerations on using IP for the satellite network. |
| Light Clients for MLS |
|
| draft-kiefer-mls-light-00.txt |
| Date: |
04/03/2024 |
| Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| Working Group: |
Individual Submissions (none) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state which can incur a significant communication and computational cost, especially when joining a group. This document defines Light MLS, an extension that allows for "light clients". A light client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a light client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| Considerations for common QoS IPv6 extension header(s) |
|
|
This document is written to start a discussion and collect opinions and ansers to questions raised in this document on the issue of defining IPv6 extension headers for DETNET-WG functionality with IPv6. |
| Messaging Layer Security Ciphersuite using XWing Key Exchange Mechanism |
|
|
This document registers a new Messaging Layer Security (MLS) ciphersuite using the X-Wing hybrid post-quantum resistant / traditional (PQ/T) Key Exchange Mechanism (KEM). |
| Self-Clocked Rate Adaptation for Multimedia |
|
|
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and is a hybrid loss- and delay based congestion control/rate management algorithm that also supports ECN and L4S. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) and 5G system simulator and is shown to achieve both low latency and high video throughput in these scenarios. This specification obsoletes RFC 8298. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. |
| Private Inexpensive Norm Enforcement (PINE) VDAF |
|
|
This document describes PINE, a Verifiable Distributed Aggregation Function (VDAF) for secure aggregation of high-dimensional, real- valued vectors with bounded L2-norm. PINE is intended to facilitate private and robust federated machine learning. |
| Secure Objects for Media over QUIC |
|
|
This document describes end-to-end encryption and authentication mechanism for application objects intended to be delivered over Media over QUIC Transport (MOQT). |
| Ranking Domain Name System data |
|
|
This document extends the list ranking the trustworthiness of domain name system (DNS) data (see Section 5.4.1 of [RFC2181]). The list is extended with entries for root server names and addresses built-in resolvers, and provided via a root hints file with the lowest trustworthiness, as wel as an entry for data which is verifiable DNSSEC secure with the highest trustworthiness. This document furthermore assigns ranked values to the positions of the list for easier reference and comparison of trustworthiness of DNS data. |
| EVPN Group Policy |
|
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. |
| Window Sizing for Zstandard Content Encoding |
|
|
Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, causing interoperability issues. This document updates the window size limit in RFC8878 from a recommendation to a requirement in HTTP contexts. |
| 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS |
|
|
5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. |
| OpenPGP Replacement Key Signalling Mechanism |
|
|
This document specifies a method in OpenPGP to suggest a replacement for an expired or revoked key. |
| SRv6 SFC Architecture with SR-aware Functions |
|
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, so that reduces nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://https/github.com/watal. |
| Secure Group Key Agreement with MLS over MoQ |
|
|
This specification defines a mechanism to use Message Layer Security (MLS) to provide end-to-end group key agreement for Media over QUIC (MOQ) applications. Almost all communications are done via the MOQ transport. MLS requires a small degree of synchronization, which is provided by a simple counter service. |
| Including Additional Records for DNSSD in DNS Push Subscriptions |
|
|
This document extends DNS Push Notifications by providing ways for DNS Push subscribers to track additional data as well as direct answers to DNS questions. This is analogous to the support for additional data specified for multicast DNS, for example. |
| MoWIE for Network Aware Application |
|
|
With the deployment of 5G networks, cloud-based interactive services such as cloud gaming have gained substantial attention. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the quality perceived by a user of a mobile and wireless device may vary widely as a function of many factors, and unhandled changes can substantially compromise the user's QoE. In this document, we investigate network-aware applications (NAA), which realize cloud-based interactive services with improved QoE, by efficient utilization of a solution named Mobile and Wireless Information Exposure (MoWIE). In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamics of the underlying network and can be made available to applications through MoWIE; using such an information, the applications can then adapt key control knobs such as media codec schemes, encapsulation, and application layer processing to minimize QoE distortion. Following evaluations we give a cursory overview of the design space for implementing MoWIE |
| Use cases,Network Scenarios and gap analysis for Packet Optical Integration (POI) with coherent plugables under ACTN Framework |
|
|
This document provides general overarching guidelines for control and management of packet over optical converged networks with coherent pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on coherent pluggables. The document provides a gap analysis to solve the use cases. |
| Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network |
|
|
This document describes the use cases and related requirements of Massive Data Transmission(MDT)in High Bandwidth-delay Product (BDP) Network. To achieve MDT, it is necessary to implement service identification and traffic record, network layer load balancing, transmission protocol optimization, etc. |
| Roughtime |
|
|
This document specifies Roughtime - a protocol that aims to achieve rough time synchronization even for clients without any idea of what time it is. 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-ietf-ntp-roughtime/. Source for this draft and an issue tracker can be found at https://github.com/wbl/roughtime-draft. |
| Selective Disclosure for JWTs (SD-JWT) |
|
|
This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. |
| SD-JWT-based Verifiable Credentials (SD-JWT VC) |
|
|
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. |
| Post-Quantum Cryptography in OpenPGP |
|
| draft-ietf-openpgp-pqc-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler |
| Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. |
| A Data Manifest for Contextualized Telemetry Data |
|
|
Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. |
| Multicast Lessons Learned from Decades of Deployment Experience |
|
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. |
| Yang Data Model for EVPN multicast |
|
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| Main logging schema for qlog |
|
|
This document defines qlog, an extensible high-level schema for a standardized logging format. It allows easy sharing of data, benefitting common debug and analysis methods and tooling. The high- level schema is independent of protocol; separate documents extend qlog for protocol-specific data. The schema is also independent of serialization format, allowing logs to be represented in many ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| QUIC event definitions for qlog |
|
|
This document describes concrete qlog event definitions and their metadata for QUIC events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| HTTP/3 qlog event definitions |
|
|
This document describes concrete qlog event definitions and their metadata for HTTP/3-related events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/ qlog/ (https://github.com/quiclog/qlog/). |
| QUIC Acknowledgment Frequency |
|
|
This document specifies an extension to QUIC that permits an endpoint to request that its peer changes 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. |
| Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) |
|
|
This document describes extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to allow participants in a multi- hop RADIUS proxy fabric to check the status of a remote RADIUS authentication realm, gain visibility into the path that a RADIUS request will take across the RADIUS proxy fabric, and mitigate or prevent RADIUS proxy loops. |
| Reference Interaction Models for Remote Attestation Procedures |
|
|
This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| A CBOR Tag for Unprotected CWT Claims Sets |
|
| draft-ietf-rats-uccs-09.txt |
| Date: |
04/03/2024 |
| Authors: |
Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann |
| Working Group: |
Remote ATtestation ProcedureS (rats) |
|
When transported over secure channels, CBOR Web Token (CWT, RFC 8392) Claims Sets may not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. |
| Direct Anonymous Attestation for the Remote Attestation Procedures Architecture |
|
| draft-ietf-rats-daa-05.txt |
| Date: |
04/03/2024 |
| Authors: |
Henk Birkholz, Christopher Newton, Liqun Chen, Dave Thaler |
| Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. |
| Attestation Results for Secure Interactions |
|
| draft-ietf-rats-ar4si-06.txt |
| Date: |
04/03/2024 |
| Authors: |
Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata |
| Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. |
| Concise Reference Integrity Manifest |
|
| draft-ietf-rats-corim-04.txt |
| Date: |
04/03/2024 |
| Authors: |
Henk Birkholz, Thomas Fossati, Yogesh Deshpande, Ned Smith, Wei Pan |
| Working Group: |
Remote ATtestation ProcedureS (rats) |
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. |
| RIFT Key/Value TIE Structure and Processing |
|
|
The RIFT (Routing in Fat-Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV- TIEs). The data contained within these KV-TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. |
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
|
| draft-ietf-schc-8824-update-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| Device Schema Extensions to the SCIM model |
|
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wifi EasyConnect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. |
| An Architecture for Trustworthy and Transparent Digital Supply Chains |
|
| draft-ietf-scitt-architecture-06.txt |
| Date: |
04/03/2024 |
| Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on any Transparency Service, with the guarantee that all Auditors and Verifiers will be able to verify them. |
| SCITT Reference APIs |
|
| draft-ietf-scitt-scrapi-01.txt |
| Date: |
04/03/2024 |
| Authors: |
Henk Birkholz, Orie Steele, Jon Geater |
| Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture [I-D.draft-ietf-scitt-architecture]. Optional key discovery and query interfaces are provided to support interoperability issues with Decentralized Identifiers, X509 Certificates and Artifact Reposistories. |
| The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 |
|
|
In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document is compatible with both. |
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) |
|
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. |
| Structured Email |
|
|
This document specifies how a machine-readable version of the content of email messages can be added to those messages. |
| Automatically Connecting Stub Networks to Unmanaged Infrastructure |
|
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). |
| YANG Data Model for Segment Routing Policy |
|
| draft-ietf-spring-sr-policy-yang-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Syed Raza, Tarik Saleh, Zhuang Shunwan, Dan Voyer, Muhammad Durrani, Satoru Matsushima, Vishnu Beeram |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. |
| YANG Data Model for SRv6 Base and Static |
|
| draft-ietf-spring-srv6-yang-03.txt |
| Date: |
04/03/2024 |
| Authors: |
Syed Raza, Sonal Agarwal, Xufeng Liu, Zhibo Hu, Iftekhar Hussain, Himanshu Shah, Dan Voyer, Hani Elmalky, Satoru Matsushima, Katsuhiro Horiba, Jaganbabu Rajamanickam, Ahmed Abdelsalam |
| Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 technology models accordingly. Additionally, this document also specifies the model for the SRv6 Static application. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| Secure Reporting of Update Status |
|
| draft-ietf-suit-report-08.txt |
| Date: |
04/03/2024 |
| Authors: |
Brendan Moran, Henk Birkholz |
| Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests |
|
|
This specification describes extensions to the SUIT manifest format defined in [I-D.ietf-suit-manifest]. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. |
| SUIT Manifest Extensions for Multiple Trust Domains |
|
|
This specification describes extensions to the SUIT Manifest format (as defined in [I-D.ietf-suit-manifest]) for use in deployments with multiple trust domains. A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. |
| Strong Assertions of IoT Network Access Requirements |
|
| draft-ietf-suit-mud-08.txt |
| Date: |
04/03/2024 |
| Authors: |
Brendan Moran, Hannes Tschofenig |
| Working Group: |
Software Updates for Internet of Things (suit) |
|
The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two. |
| Scalability Considerations for Network Resource Partition |
|
| draft-ietf-teas-nrp-scalability-04.txt |
| Date: |
04/03/2024 |
| Authors: |
Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra |
| Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC XXXX describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| TLS Encrypted Client Hello |
|
| draft-ietf-tls-esni-18.txt |
| Date: |
04/03/2024 |
| Authors: |
Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher Wood |
| Working Group: |
Transport Layer Security (tls) |
|
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. 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/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). |
| Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) |
|
| draft-ietf-tsvwg-rfc4895-bis-02.txt |
| Date: |
04/03/2024 |
| Authors: |
Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig |
| Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895. |
| TVR (Time-Variant Routing) Requirements |
|
|
Time-Variant Routing (TVR) refers to the calculation of a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements where TVR computations could improve message exchange in a network. |
| Selectively Isolating Hosts to Prevent Potential Neighbor Discovery Issues and Simplify IPv6 First-hops |
|
|
Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses multicast extensively and trusts all hosts. In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable. Consequently, ND has potential issues in various scenarios. The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview is useful. This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference. Analyzing these solutions reveals an insight: isolating hosts is effective in preventing ND issues. Five isolation methods are proposed and their applicability is discussed. Guidelines are described for selecting a suitable isolation method based on the deployment scenario. When ND issues are prevented with a proper isolation method, the solutions for these issues are not needed. This simplifies the IPv6 first- hops. |
| The WebTransport Protocol Framework |
|
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. |
| WebTransport over HTTP/3 |
|
|
WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. |
| WebTransport over HTTP/2 |
|
| draft-ietf-webtrans-http2-08.txt |
| Date: |
04/03/2024 |
| Authors: |
Alan Frindell, Eric Kinnear, Tommy Pauly, Martin Thomson, Victor Vasiliev, Guowu Xie |
| Working Group: |
WebTransport (webtrans) |
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. |
|
|
| |
| Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) |
|
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. |
| CBOR Common Deterministic Encoding (CDE) |
|
| draft-ietf-cbor-cde-02.txt |
| Date: |
03/03/2024 |
| Authors: |
Carsten Bormann |
| Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) Profile that can be shared by a large set of applications with potentially diverging detailed requirements. This document also introduces the concept of Application Profiles, which are layered on top of the CBOR CDE Profile and can address more application specific requirements. Application Profiles are defined in separate documents. |
| Domain Control Validation using DNS |
|
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the application service provider requesting a DNS record with a specific format and content to be visible in the requester's domain. There is wide variation in the details of these methods today. This document proposes some best practices to avoid known problems. |
| Link relationship types for authentication |
|
|
This specification defines a set of relationships that may be used to indicate where a user may authenticate, log out, register a new account or find out who is currently authenticated. |
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) |
|
|
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known as Kyber, is a key-encapsulation mechanism (KEM). This document specifies algorithm identifiers and ASN.1 encoding format for ML-KEM in public key certificates. The encoding for public and private keys are also provided. [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] |
| IS-IS YANG Model Augmentations for Additional Features - Version 1 |
|
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, IS-IS Application-Specific Link Attributes as defined in RFC 8919, IS-IS Flexible Algorithm as defined in RFC 9350, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. |
| YANG Data Model for OSPF SRv6 |
|
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. |
| Guidelines for the Definition of New Top-Level Media Types |
|
|
This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. [RFC Editor, please remove this paragraph.] Comments and discussion about this document should be directed to media-types@ietf.org, the mailing list of the Media Type Maintenance (mediaman) WG. Alternatively, issues can be raised on GitHub at https://github.com/ ietf-wg-mediaman/toplevel. |
| Multiple Upstream Interface Support for IGMP/MLD Proxy |
|
|
This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface can be selected based on multiple criteria, such as the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described. |
| Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets |
|
|
RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification of the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets for which the verification tag can not be checked. |
| BGP Extension For L3VPN Performance Monitoring |
|
|
This document describes a new VT address family in BGP to exchange information required for apply performance monitoring in MPLS/BGP VPN, as described in [I-D.dong-l3vpn-pm-framework]. |
| Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing |
|
| draft-perkins-manet-aodvv2-04.txt |
| Date: |
03/03/2024 |
| Authors: |
Charles Perkins, John Dowdell, Lotte Steenbrink, Victoria Pritchard |
| Working Group: |
Individual Submissions (none) |
|
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. |
| CoAP: Non-traditional response forms |
|
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated. |
| BMP for BGP Route Leak Detection |
|
|
According to Route-Leak Problem Definition [RFC7908], Route leaks refer to the case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to prevent the happening of BGP [RFC4271] route leaks. However, the real-time route leak detection if any occurs is important as well, and serves as the basis for leak mitigation. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks at the prefix level. |
| General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
|
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| Enhanced AS-Loop Detection for BGP |
|
|
Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection. |
| A YANG Data Model for Client Signal Performance Monitoring |
|
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| Using Flex-Algo for Segment Routing (SR) based Network Resource Partition (NRP) |
|
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique Flexible Algorithm (Flex-Algo), which can provide constraint-path computation based on the customized topological constraints. This document specifies a mechanism to build Segment Routing (SR) based NRPs by combining SR Flex-Algo and IGP L2 bundles with minor extensions. |
| SVG Tiny Portable/Secure |
|
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| Fetch and Validation of Verified Mark Certificates |
|
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| BIMI Reporting |
|
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| Brand Indicators for Message Identification (BIMI) |
|
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| Advertisement of Dedicated Metric for Flexible Algorithm in IGP |
|
|
This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. |
| Advertising Exclusive Links for Flex-Algorithm in IGP |
|
|
This document proposes the method to advertise exclusive links for Flex-Algorithm in IGP. |
| UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
|
|
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality needed within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. |
| Design Space Analysis of MoQ |
|
|
This document investigates potential solution directions within the charter scope of MoQ WG. MoQ aims to provide low-latency, efficient media delivery solution for use cases including live streaming, gaming and video conferencing. To achieve low-latency media transfer efficiently, the network topology of relay nodes and the computation done at the relay nodes should be considered carefully. This document provides the analysis of those factors which can help the design of the MoQ protocols. |
| General Source Address Validation Capabilities |
|
| draft-huang-savnet-sav-table-05.txt |
| Date: |
03/03/2024 |
| Authors: |
Mingqing(Michael) Huang, Weiqiang Cheng, Dan Li, Nan Geng, Mingxing Liu, Li Chen, Changwang Lin |
| Working Group: |
Individual Submissions (none) |
|
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. |
| BGP over QUIC |
|
| draft-retana-idr-bgp-quic-04.txt |
| Date: |
03/03/2024 |
| Authors: |
Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura |
| Working Group: |
Individual Submissions (none) |
|
This document specifies the use of QUIC Streams to support multiple BGP sessions over one connection in order to achieve high resiliency. |
| Source IPv6 Address Programmability |
|
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information |
| MoQ relay for support of deadline-aware media transport |
|
|
This draft specifies the behavior of MoQ relays for delivering media before the deadline to decrease end-to-end latency and save transport costs in media transmission. To achieve this, the draft introduces deadline-aware actions prioritizing media streams with earlier deadlines, ensuring timely transmission while minimizing costs. |
| Network Management Intent -One of IBN Use Cases |
|
|
Full life cycle network management will be a key feature of the future communication networks. Meanwhile, the complexity of the network management should be reduced and the network expects to be managed in a fully automated manner with humans out of the loop. In this document, we propose an use case of intent based network management to achieve more flexible , convenient, and efficient network management. In this use case, we propose an architecture and attempt to illustrate the five levels of achieving full autonomous network management. |
| Selective Synchronization for RPKI to Router Protocol |
|
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronizations. The router can obtain only the data that it really needs, and it does not need to save the data that are not needed. |
| Routing mechanism in Dragonfly Networks Gap Analysis,Problem Statement,and Requirements |
|
|
This document provides the gap analysis of existing routing mechanism in dragonfly networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) |
|
| draft-li-savnet-sav-yang-04.txt |
| Date: |
03/03/2024 |
| Authors: |
Dan Li, Fang Gao, Changwang Lin, Jianping Wu, Tianhao Wu, Weiqiang Cheng |
| Working Group: |
Individual Submissions (none) |
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. |
| SAVI in an EVPN network |
|
|
Source Address Validation procedures have been specified in the SAVI Working Group and provide a set of mechanisms and state machines to verify Source Address ownership. The main mechanisms are described in RFC6620 and RFC7513. RFC7432 and furthermore RFC9161 specify how an EVPN network could learn and distribute IP addressess. RFC9161 describes a mechanism by which the PE can proxy some ND messages based on this information. In this document, we review how these two sets of specifications and underlying mechanisms can interact to provide Source Address Validation in an EVPN network. |
| Using QUIC to traverse NATs |
|
|
QUIC is well-suited to various NAT traversal techniques. As it operates over UDP, and because the QUIC header was designed to be demultipexed from other protocols, STUN can be used on the same UDP socket, enabling ICE to be used with QUIC. Furthermore, QUIC’s path validation mechanism can be used to test the viability of an address candidate pair while at the same time creating the NAT bindings required for a direction connection, after which QUIC connection migration can be used to migrate the connection to a direct path. |
| CBOR: On Deterministic Encoding |
|
|
CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2. The present document provides additional information about use cases, deployment considerations, and implementation choices for Deterministic Encoding. |
| Use Cases for SPICE |
|
|
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation. |
| IS-IS and OSPF extensions for TVR (Time-Variant Routing) |
|
|
TVR needs IGP to calculate different results depending on the time, without convergence after the detection of link or nodes. IGP nodes need to learn the predictable and scheduled changes in advance. This document defines the IGP extensions for predictable and scheduled changes of TVR. |
| BGP Flow Specification for Source Address Validation |
|
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document specifies a new flow specification called Incoming- Interface-Set. Incoming-Interface-Set can be used together with the Source Prefix component to disseminate SAV rules. |
| A YANG Data Model for Microwave Radio Link |
|
| draft-ybam-rfc8561bis-01.txt |
| Date: |
03/03/2024 |
| Authors: |
Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala |
| Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. |
| YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) |
|
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). |
| Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST) |
|
|
Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) define protocol messages for X.509v3 certificate creation and management. Both protocol provide interactions between client systems and PKI management entities, such as a Registration Authority (RA) and a Certification Authority (CA). CMP and EST allow an RA/CA to request additional information it has to provide in a certification request. When an end entity places attestation Evidence in a Certificate Signing Request (CSR) it may need to demonstrate freshness of the provided Evidence. Attestation technology today often accomplishes this task via the help of nonces. This document specifies how nonces are provided by an RA/CA to the end entity for inclusion in Evidence. |
| SRv6 Security Considerations |
|
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. |
| Extended Key Update for Transport Layer Security (TLS) 1.3 |
|
|
The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. |
| NASR Use Case and Requirements |
|
| draft-liu-nasr-requirements-01.txt |
| Date: |
03/03/2024 |
| Authors: |
Peter Liu, Luigi Iannone, Diego Lopez, Antonio Pastor, Meiling Chen, Li Su |
| Working Group: |
Individual Submissions (none) |
|
This document describes the use cases and requirements that guide the specification of a Network Attestation for Secure Routing framework (NASR). |
| Path-aware Remote Protection Framework |
|
|
This document describes the framework of path-aware remote protection. |
| EAT Measured Component |
|
|
This document defines a "measured components" format that can be used with the EAT Measurements claim. |
| SNMP Trap for SRv6 Policy |
|
|
This document defines the Simple Network Management Protocol (SNMP) trap module for SRv6 Policy. |
| Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives |
|
| draft-havel-nmop-digital-map-00.txt |
| Date: |
03/03/2024 |
| Authors: |
Olga Havel, Benoit Claise, Oscar de Dios, Ahmed Elhassany, Thomas Graf, Mohamed Boucadair |
| Working Group: |
Individual Submissions (none) |
|
This document shares experience in modelling Digital Map based on the IETF RFC 8345 topology YANG modules and some of its augmentations. First, the concept of Digital Map is defined and its connection to the Digital Twin is explained. Next to Digital Map requirements and use cases, the document identifies a set of open issues encountered during the modelling phases, the missing features in RFC 8345, and some perspectives on how to address them. 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/OlgaHuawei. |
| Vector Commitment-based Proof of Transit |
|
|
This document describes an ordered Proof of Transit mechanism. |
| IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
|
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. |
| The UDP Authentication Option |
|
|
This document extends UDP by defining a framework for an authentication option. |
| Telemetry Methodologies for Analog Measurement Instrumentation |
|
|
Evolution toward network operations automation requires systems encompassing software-based analytics and decision-making. Network- based instrumentation provides crucial data for these components and processes. However, the proliferation of such instrumentation and the need to migrate the data it generates from the physical network to "off-the-network" software, poses challenges. In particular, analog measurement instrumentation, which generates time-continuous real number data, may generate significant data volumes. Methodologies for handling analog measurement instrumentation data will need to be identified and discussed, informed in part by consideration of requirements for the operation of network digital twins, which may be important software-realm consumers of such data. |
| YANG Model for IS-IS Segment Routing MPLS PICS |
|
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. |
| IKEv2 support for Child SA PFS policy notification |
|
|
This document defines the CHILD_PFS_INFO Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support exchanging the policy for the Perfect Forward Secrecy (PFS) and Key Exchange (KE) method setting of the initial Child SA. |
| YANG Data Models for Transport TE FGNM Extension Model |
|
|
This document defines two extension YANG data models augmenting to TE topology and TE tunnel YANG model, based on the FGNM (Fine-Grain Network Management) requirements in transport networks. |
| Mobile User Plane Architecture for Distributed Mobility Management |
|
| draft-mhkk-dmm-mup-architecture-00.txt |
| Date: |
03/03/2024 |
| Authors: |
Satoru Matsushima, Katsuhiro Horiba, Ashiq Khan, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Miya Kohno, Teppei Kamata, Pablo Camarillo, Jakub Horn, Dan Voyer, Shay Zadok, Israel Meilik, Ashutosh Agrawal, Kumaresh Perumal |
| Working Group: |
Individual Submissions (none) |
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case due to the DMM requirement, and is suitable for mobile services which require a large IP address space. |
| Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks |
|
|
This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, and audio/video production. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications. |
| Data Fields for Congestion Measurement |
|
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement command in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrive at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, aids in effective load balancing, and simplifies network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. |
| IGP Extensions for Source Prefix Identification |
|
|
This document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI. |
| IPv6 Options for Congestion Measurement |
|
|
The Congestion Measurement enables precise congestion control, aids in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document outlines how Congestion Measurement Data-Fields are encapsulated in IPv6. |
| IOAM network awareness for Low Latency,Low Loss,and Scalable Throughput (L4S) |
|
| draft-quan-l4s-ioam-00.txt |
| Date: |
03/03/2024 |
| Authors: |
Wei Quan, Wei Su, Shuaihao Pan, Xiaobin Liang, Jie Liang |
| Working Group: |
Individual Submissions (none) |
|
This specification defines a framework how to update L4S Dual-Queue Coupled AQM with In Situ Operations, Administration, and Maintenance (IOAM). These are designed for consistently very low queuing latency, very low congestion loss, and scaling of perflow throughput by using Explicit Congestion Notification (ECN) using the operational and telemetry information collected by IOAM. Since L4S lacks information about the use of network status and network nodes, which also affect network performance in practice, it is considered to use direct export mode for information collection of L4S-IOAM to strengthen the AQM regulation of L4S. It then gives the normative requirements that are necessary. |
| IKEv2 Support for Anti-Replay Status Notification |
|
|
RFC 4302 and RFC 4303 specify that, during Security Association (SA) establishment, IPsec implementation should notify the peer if it will not provide anti-replay protection, to avoid having the peer do unnecessary sequence number monitoring and SA setup. This document defines the ANTI_REPLAY_STATUS Notify Message Status Type Payload in the Internet Key Exchange Protocol Version 2 (IKEv2) to inform the peers of their own anti-replay status when creating the IPsec SAs, to fulfill the above requirement. |
| Shared Use of IPsec Tunnel in a Multi-VPN Environment |
|
|
In a multi-VPN environment, currently, different IPsec tunnels (i.e., different IKE SAs and Child SAs) have to be created to differentiate and protect the traffic of each VPN between the device and its peer. When the number of neighbors of a device and the number of VPNs increases, the number of IPsec tunnels also increases considerably. This results in the need for a large number of SAs, which exceeds the device's capacity. This document proposes a method for different VPNs to share the use of a single IPsec tunnel, which can greatly reduce the number of SAs required in a multi-VPN scenario. |
| Token Status List |
|
|
This specification defines status list data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption(COSE), such as JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs) and ISO mdoc. The status list token data structures themselves are also represented as JWTs or CWTs. |
| PCEP extensions for p2mp sr policy |
|
| draft-ietf-pce-sr-p2mp-policy-05.txt |
| Date: |
03/03/2024 |
| Authors: |
Hooman Bidgoli, Dan Voyer, Saranya Rajarathinam, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| Working Group: |
Path Computation Element (pce) |
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. |
| Segment Routing based Network Resource Partition (NRP) for Enhanced VPN |
|
|
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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. |
| Encrypted Payloads in SUIT Manifests |
|
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. |
| The Transport Layer Security (TLS) Protocol Version 1.3 |
|
|
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. |
| TLS/DTLS 1.3 Profiles for the Internet of Things |
|
|
This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile. 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/thomas-fossati/draft-tls13-iot. |
|
|
| |
| BRSKI-AE: Alternative Enrollment Protocols in BRSKI |
|
| draft-ietf-anima-brski-ae-10.txt |
| Date: |
01/03/2024 |
| Authors: |
David von Oheimb, Steffen Fries, Hendrik Brockhaus |
| Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995). It supports alternative certificate enrollment protocols, such as CMP, that use authenticated self-contained signed objects for certification messages. This offers the following advantages. The origin of requests and responses can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where and when to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. |
| EVPN Network Layer Fault Management |
|
| draft-ietf-bess-evpn-bfd-06.txt |
| Date: |
01/03/2024 |
| Authors: |
Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake |
| Working Group: |
BGP Enabled ServiceS (bess) |
|
This document specifies proactive, in-band network layer OAM mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (RFC 7432bis) network. The mechanisms specified in the draft use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol and other protocols as necessary. |
| YANG Data Models for requesting Path Computation in WDM Optical Networks |
|
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments 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. |
| A YANG Data Model for WDM Tunnels |
|
| draft-ietf-ccamp-wdm-tunnel-yang-01.txt |
| Date: |
01/03/2024 |
| Authors: |
Aihua Guo, Sergio Belotti, Gabriele Galimberti, Universidad de Madrid, Daniel Burrero |
| Working Group: |
Common Control and Measurement Plane (ccamp) |
|
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). |
| CDNI Protected Secrets Metadata |
|
|
This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. |
| The JMAPACCESS Extension for IMAP |
|
|
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via JMAP, and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. |
| BGP Next Hop Dependent Capabilities Attribute |
|
| draft-ietf-idr-entropy-label-14.txt |
| Date: |
01/03/2024 |
| Authors: |
Bruno Decraene, John Scudder, Wim Henderickx, Kireeti Kompella, MOHANTY Satya, Jim Uttaro, Bin Wen |
| Working Group: |
Inter-Domain Routing (idr) |
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain capabilities, or other properties, to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such capability information, the "Next Hop Dependent Capabilities Attribute," or NHC. Unlike the capabilities defined by RFC 5492, those conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. This specification also defines an NHC capability that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. |
| Responsiveness under Working Conditions |
|
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of latency, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. |
| JSON Proof Token |
|
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). |
| JSON Web Proof |
|
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay. |
| JSON Proof Algorithms |
|
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof and JSON Web Key (JWK) specifications. It defines IANA registries for these identifiers. |
| Header Protection for Cryptographically Protected E-mail |
|
|
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification ([RFC8551]) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The Header Protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. |
| Use of Remote Attestation with Certificate Signing Requests |
|
|
A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document defines a new PKCS#10 attribute attr-evidence and CRMF extension ext-evidence that allows placing any Evidence data, in any pre-existing format, along with any certificates needed to validate it, into a PKCS#10 or CRMF CSR. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). |
| A YANG Data Model for MPLS Static LSPs |
|
| draft-ietf-mpls-static-yang-14.txt |
| Date: |
01/03/2024 |
| Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). |
| Egress Validation in Label Switched Path Ping and Traceroute Mechanisms |
|
|
The MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for Segment Routing(SR) as defined in RFC 8287 is very useful to validate the control plane and data plane synchronization. In some environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A simple MPLS ping and traceroute mechanism allows traversing any path without validating the control plane state. RFC 8029 supports this mechanism with Nil Forwarding Equivalence Class (FEC). The procedures described in RFC 8029 mostly apply when the Nil FEC is used as an intermediate FEC in the label stack. When all labels in the label stack are represented using Nil FEC, it poses some challenges. This document introduces a new Type-Length-Value (TLV) as an extension to exisiting Nil FEC. It describes MPLS ping and traceroute procedures using Nil FEC with this extension to overcome these challenges. |
| Deprecating the Use of Router Alert in LSP Ping |
|
|
The MPLS echo request and MPLS echo response messages, defined in RFC 8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP ping messages), are encapsulated in IP whose headers include a Router Alert Option (RAO). In actual deployments, the RAO was neither required nor used. Furthermore, RFC 6398 identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM), and recommends against its use outside of controlled environments. Therefore, this document retires the RAO for MPLS OAM and updates RFC 8029 to remove the RAO from LSP ping message encapsulations. Furthermore, this document explains why RFC 7506 has been reclassified as Historic. Also, the use of an IPv6 loopback address (::1/128) as the IPv6 destination address for an MPLS echo request message is RECOMMENDED. |
| List Pagination for YANG-driven Protocols |
|
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| NETCONF Extensions to Support List Pagination |
|
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| RESTCONF Extensions to Support List Pagination |
|
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET and DELETE operations, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. |
| Transaction ID Mechanism for NETCONF |
|
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is an inefficient mechanism for synchronization. This document specifies an extension to NETCONF that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. |
| NETCONF Private Candidates |
|
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| Updated YANG Module Revision Handling |
|
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. |
| Load Sharing for the Stream Control Transmission Protocol (SCTP) |
|
| draft-tuexen-tsvwg-sctp-multipath-27.txt |
| Date: |
01/03/2024 |
| Authors: |
Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen |
| Working Group: |
Individual Submissions (none) |
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. |
| NEAT Sockets API |
|
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. |
| VXLAN-GPE Encapsulation for In Situ OAM (IOAM) Data |
|
| draft-brockners-ippm-ioam-vxlan-gpe-05.txt |
| Date: |
01/03/2024 |
| Authors: |
Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel |
| Working Group: |
Individual Submissions (none) |
|
In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in VXLAN-GPE. |
| A Framework for Constructing Service Function Chaining Systems Based on Segment Routing |
|
|
Segment Routing (SR) introduces a versatile methodology for defining end-to-end network paths by encoding sequences of topological sub- paths, known as "segments". This architecture can be deployed over both MPLS and IPv6 data planes, offering a flexible routing solution. Service Function Chaining (SFC) supports the establishment of composite services through an ordered sequence of Service Functions (SFs) that are applied to packets or frames based on initial classification. SFC's implementation can utilize various underlying technologies, including the Network Service Header (NSH) and SR, to facilitate the creation and management of service chains. This document presents a comprehensive control framework for developing SFC architectures using Segment Routing. It explores control plane solutions for the distribution of service function instance routes and service function paths, as well as techniques for directing packets into specific service function chains. The discussion encompasses both theoretical foundations and practical considerations for integrating SR into SFC deployments. |
| SRv6 for Inter-Layer Network Programming |
|
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines an SRv6 based mechanism for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. A new SRv6 behavior called End.XU is introduced, which is a variant of the SRv6 End.X behavior. Instead of pointing to an interface with layer-3 adjacency, the End.XU behavior points to an underlay interface which connects to a remote layer-3 node via underlying links or connections that are invisible in the L3 network topology. The applicability of the End.XU behavior in typical inter- layer network programming scenarios is also illustrated. |
| Stateless OpenPGP Command Line Interface |
|
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security. |
| IETF Network Slice Topology YANG Data Model |
|
|
An IETF network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for configuring customer intent topologies for network slices using IETF technologies defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-ietf-network-slices once it has been published. |
| Deadline Based Deterministic Forwarding |
|
|
This document describes a deterministic forwarding mechanism to IP/ MPLS network, as well as corresponding resource reservation, admission control, policing, etc, to provide guaranteed latency. Especially, latency compensation with core stateless is discussed to replace reshaping to be suitable for Diff-Serv architecture [RFC2475]. |
| Requirement of Fast Fault Detection for IP-based Network |
|
| draft-guo-ffd-requirement-02.txt |
| Date: |
01/03/2024 |
| Authors: |
Liang Guo, Yi Feng, Jizhuang Zhao, Fengwei Qin, Lily Zhao, Haibo Wang, Wei Quan, Hongyi Huang |
| Working Group: |
Individual Submissions (none) |
|
The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. This document describes the requirements for a fast fault detection solution of IP-based network. |
| Framework of Fast Fault Detection for IP-based Network |
|
| draft-wang-ffd-framework-02.txt |
| Date: |
01/03/2024 |
| Authors: |
Haibo Wang, Fengwei Qin, Lily Zhao, Shuanglong Chen, Hongyi Huang |
| Working Group: |
Individual Submissions (none) |
|
The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. IP-based storage network is the typical usage of that scenario. When the IP-based storage network fault occurs, NVMe connections need to be switched over. Currently, no effective method is available for quick detection, switchover is performed only based on keepalive timeout, resulting in low performance. This document defines the basic framework of how network assisted host devices can quickly detect application connection failures caused by network faults. |
| Additional XML Security Uniform Resource Identifiers (URIs) |
|
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes RFC 9231. |
| A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
|
|
This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document obsoletes RFC 8347. |
| Design analysis of methods for distributing the computing metric |
|
|
This document analyses different methods for distributing the computing metrics from service instances to the ingress router. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Computing-Aware Traffic Steering Working Group mailing list (cats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cats/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-cats-method-analysis. |
| Communicating Proxy Configurations in Provisioning Domains |
|
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and a list of DNS zones that are accessible via a proxy. 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/tfpauly/privacy-proxy. |
| Validity of SR Policy Candidate Path |
|
|
An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active (i.e., installed in forwarding and usable for steering of traffic). Each CP in turn may have one or more SID-List of which one or more may be active; when multiple SID-List are active then traffic is load balanced over them. However, a candidate path is valid when at least one SID-List is active. This candidate path validity criterion cannot meet the needs of some scenarios. This document defines the new candidate path validity criterion. |
| Validity of SR Policy Candidate Path |
|
|
This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy. |
| Applying COSE Signatures for YANG Data Provenance |
|
|
This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. |
| Advertisement of Candidate Path Validity Control Parameters using BGP-LS |
|
|
This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc. |
| Generic Address Assignment Option for 6LowPAN Neighbor Discovery |
|
|
This document specifies a new extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks enabling a node to request to be assigned an address or a prefix from neighbor routers. Such mechanism allows to recursively assign addresses and prefixes to nodes in a 6LowPAN deployment. |
| PCEP extension to support Candidate Paths validity |
|
|
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy. |
| First-Party Approved Third-Party Certifications in OpenPGP |
|
|
An OpenPGP certificate can grow in size without bound when third- party certifications are included. This document describes a way for the owner of the certificate to explicitly approve of specific third- party certifications, so that relying parties can safely prune the certificate of any unapproved certifications. |
| Signaling MNA Capability Using IGP and BGP-LS |
|
|
This document defines a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS). |
| OAuth 2.0 for First-Party Applications |
|
|
This document defines the Authorization Challenge Endpoint, which supports a first-party client that wants to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions. |
| SRH Reduction for SRv6 End.M.GTP6.E Behavior |
|
|
Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. |
| Application-aware Data Center Network (APDN) Use Cases and Requirements |
|
|
The deployment of large-scale AI services within data centers introduces significant challenges to established technologies, including load balancing and congestion control. Additionally, the adoption of cutting-edge network technologies, such as in-network computing, is on the rise within AI-centric data centers. These advanced network-assisted application acceleration technologies necessitate the flexible exchange of cross-layer interaction information between end-hosts and network nodes. The Application-aware Data Center Network (APDN) leverages the Application-aware Networking (APN) framework for application side to furnish the data center network with detailed application-aware information. This approach facilitates the rapid advancement of network-application co-design technologies. This document delves into the use cases of APDNs and outlines the associated requirements, setting the stage for enhanced performance and efficiency in data center operations tailored to the demands of AI services. |
| EAP-FIDO |
|
|
This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP. 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-janfred-eap-fido/. Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/. |
| Post-Quantum Cryptography Recommendations for Internet Applications |
|
|
Post-quantum cryptography brings some new challenges to applications, end users, and system administrators. This document describes characteristics unique to application protocols and best practices for deploying Quantum-Ready usage profiles for applications using TLS. |
| Procedures and Extension for VLAN-based Traffic Forwarding |
|
|
This document defines the data plane operations around VLAN switching and describes a standard method for implementing VLAN tags, and thus the desired tag manipulation can be achieved. |
| Flow Aggregation for Enhanced DetNet |
|
|
This document describes the flow aggregation scenarios and proposes a method by aggregating DetNet flows based on DetNet flow-specific classification in enhanced DetNet and the flow identification of aggregated-class can be used to indicate the required treatment and forwarding behaviors in scaling networks. |
| Extended YANG Data Model for DOTS |
|
|
With the development of DDoS defense technologies, the interfaces and parameters defined by DOTS are no longer sufficient to support the collaborative signaling required between DDoS mitigation systems. This document defines three YANG model to extend the data models of existing interfaces on the DOTS signaling and data channels, with the aim of supporting the transmission of necessary collaborative information between DDoS mitigation systems via DOTS and enabling efficient collaborative mitigation based on this information. |
| No Further Fast Reroute for SRv6 Service SID |
|
|
In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR flags for SRv6 Service SIDs in BGP messages. |
| SRv6 Service SID Anycast Flag |
|
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines the Anycast-flag for SRv6 Service SIDs carried in BGP messages. |
| Constrained Application Protocol (CoAP) over Bundle Protocol (BP) |
|
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. |
| Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
|
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| Unrelated name server name requirement |
|
|
Unrelated(out-of-bailiwick) name server names are required for DNS hosting services. However, using unrelated name server names increases the name resolution costs. This document proposes using in-domain name servers as much as possible for name resolution of unrelated name server names to reduce the name resolution costs. |
| List Pagination Snapshots for YANG-driven Protocols |
|
|
List pagination for YANG-driven protocols are defined in [I-D.ietf-netconf-list-pagination]. Operational data can have very large data sets. These data sets can furthermore have big churn, a lot of additions or deletions to the data set. In order to support a stable pagination of such data sets, snapshots can be used. This document defines snapshot support for pagination of "config false" nodes of type "list" and "leaf-list". The snapshot support for individual nodes is signaled via the "ietf-system-capabilities" module. |
| Advance Professional Video |
|
| draft-lim-apv-00.txt |
| Date: |
01/03/2024 |
| Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| Working Group: |
Individual Submissions (none) |
|
This document describes bitstream format of Advanced Professional Video and decoding process of it. |
| MKA over IP |
|
|
Extensible Authentication Protocol (EAP) is described in [RFC3748]. EAP typically runs directly over data link layers such as Point-to- Point Protocol (PPP) or IEEE 802, without requiring IP. IEEE802.1X-2004 clarifies some aspect of the EAP over Layer 2 PDUs. IEEE802.1X-2010 introduces MACsec Key Agreement Protocol (MKA) which uses EAPOL. In IEEE 802.1X-2010 the existing EAPOL (EAP over LANs) PDU formats have not been modified, but additional EAPOL PDUs have been added to support MKA. MKA is used for discovering peers and their mutual authentication, to agree the secrete keys (SAKs) used by MACsec for symmetric shared key cryptography. This document describes procedures to transport EAP and ultimately MKA PDUs over a IP network to distribute SAKs for symmetric key cryptography. |
| Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications |
|
| draft-schott-sip-avors-00.txt |
| Date: |
01/03/2024 |
| Authors: |
Roland Schott, Michael Kreipl, Bastian Dreyer, Roland Jesske |
| Working Group: |
Individual Submissions (none) |
|
This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active registrations. The concept can be mapped on any architecture having a distributed structure and could work for different protocols. The concept is exemplary explained here regarding an architecture for voice and is mapped on a 3GPP (3rd Generation Partnership Project) architecture. This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active UE (User Equipment) registrations on other Outbound Proxies (P-CSCF) within the SIP voice architecture. The AVORS concept increases service continuity, improves network resilience, and offers savings potential. Additionally, this document gives an outlook regarding stateless voice architectures, load calculation aspects, and Service Based Interfaces (SBI) in context data base interworking. Security aspects are considered in the security chapter. As stated above the AVORS principle is not only limited to the SIP protocol and could be adopted by other protocols. |
| Identity Assertion Authorization Grant |
|
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. |
| Authorized update to MUD URLs |
|
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) |
|
|
This document discusses the applicability of Bidirectional Forwarding Detection (BFD) for multipoint networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second convergence of the Active router and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798bis [Ed.Note: When the RFC 5798bis is published, change to the assigned new number]. |
| Cursor-based Pagination of SCIM Resources |
|
|
This document defines additional SCIM (System for Cross-Domain Identity Management) query parameters and result attributes to allow use of cursor-based pagination in SCIM implementations that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well established. |