| |
|
| |
| | Transmission of SCHC-compressed packets over IEEE 802.15.4 networks |
| |
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. |
| | Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks |
| |
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables IP packet stateless forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. These specifications describe the PASA architecture, along with PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. |
| | Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events |
| |
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8106. |
| | IPv6 Node Requirements |
| |
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. |
| | 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-07.txt |
| | Date: |
03/03/2025 |
| | 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 between the client and resource server 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-07.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys |
| | Working Group: |
Authentication and Authorization for Constrained Environments (ace) |
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. |
| | Short Distribution Chain (SDC) Workflow and New 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. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings, and extends the semantics of the "ace_profile" parameter. (3) It defines how the client and the authorization server can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (4) It amends two of the requirements on profiles of the framework. (5) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles 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. |
| | Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. |
| | 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. |
| | BRSKI Cloud Registrar |
| |
| | draft-ietf-anima-brski-cloud-14.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Owen Friel, Rifaat Shekh-Yusef, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. This document extends BRSKI and defines new device behavior for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. |
| | EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols |
| |
|
The existing EVPN multi-homing load-balancing modes do not adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, etc. This document defines a new multi-homing mechanism to support these loop-preventing Layer-2 protocols. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |
| | PIM Signaling Through BIER Core |
| |
| | draft-ietf-bier-pim-signaling-13.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Hooman Bidgoli, Fengman Xu, Jayant Kotalwar, IJsbrand Wijnands, Mankamana Mishra, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Consider large networks deploying traditional PIM multicast service. Typically, each portion of these large networks have their own mandates and requirements. It might be desirable to deploy BIER technology in some part of these networks to replace traditional PIM services. In such cases downstream PIM states need to be signaled over the BIER Domain toward the source. This document specifies the procedures to signal PIM Join and Prune messages through a BIER Domain using [RFC9739] , enabling the provisioning of traditional PIM services through a BIER Domain. These procedures are valid for forwarding PIM Join/Prune messages to the Source (SSM) or Rendezvous Point (ASM). |
| | Benchmarking Methodology for Segment Routing |
| |
| | draft-ietf-bmwg-sr-bench-meth-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
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. |
| | CATS Metrics Definition |
| |
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a given service instance by considering the dynamic nature of computing and network resources. In order to consider the computing and network resources, a system needs to share information (metrics) that describes the state of the resources. Metrics from network domain have been in use in network systems for a long time. This document defines a set of metrics from computing domain used for CATS. |
| | Packed CBOR |
| |
| | draft-ietf-cbor-packed-14.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Carsten Bormann, Mikolai Guetschow |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // The present version (-14) adds additional stand-in items to the // previously updated implementation draft -13, with minor editorial // improvements. |
| | CDDL Module Structure |
| |
| | draft-ietf-cbor-cddl-modules-04.txt |
| | Date: |
03/03/2025 |
| | 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 9682 as well as 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. |
| | CDNI Edge Control Metadata |
| |
|
This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. |
| | 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. |
| | Hedged ECDSA and EdDSA Signatures |
| |
|
Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. |
| | The BBS Signature Scheme |
| |
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. |
| | Deterministic Nonce-less Hybrid Public Key Encryption |
| |
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. |
| | Blind BBS Signatures |
| |
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. |
| | BBS per Verifier Linkability |
| |
|
The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. |
| | 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. |
| | CoAP Transport Indication |
| |
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. |
| | 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, and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document 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 typically 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 TLSA selectors registry defined in RFC 6698 is extended to include CBOR certificates. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. |
| | 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 domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC |
| |
|
Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. |
| | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) |
| |
| | draft-ietf-emu-eap-edhoc-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, Francisco Lopez |
| | Working Group: |
EAP Method Update (emu) |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. |
| | 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-ietf-emu-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/. |
| | Logging of routing events in BGP Monitoring Protocol (BMP) |
| |
|
The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis. |
| | File-Like ICN Collections (FLIC) |
| |
| | draft-irtf-icnrg-flic-07.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Christian Tschudin, Christopher Wood, Marc Mosko, David Oran |
| | Working Group: |
Information-Centric Networking (icnrg) |
|
This document describes how to encode an application data objet into a structured _manifest_ using Information Centric Networking (ICN) data objects, creating a File-Like ICN Collection (FLIC). The manifest is an "index table" of objects that make up the manifest itself and the application data. It records the hash value (content object hash) of each item so a consumer using the manifest may request each piece by a complete hash name. The manifest is hierarchical and may be encoded into realtively small ICN objects to fit within network MTU sizes. FLIC has several methods to guide a consumer in constructing appropriate Interest names based on the manifest. It also supports encryption of the manifest data. FLIC may be used in CCNx or Named Data Networking, or other ICNs. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-11.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Prodosh Mohapatra, Rex Fernando, Reshma Das, MOHANTY Satya, Mankamana Mishra, Rafal Szarecki |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. |
| | BGP SR Policy Extensions for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. |
| | BGP Flow Specification Version 2 - for Basic IP |
| |
| | draft-ietf-idr-fsv2-ip-basic-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Susan Hares, Donald Eastlake, Jie Dong, Chaitanya Yadlapalli, Sven Maduschke |
| | Working Group: |
Inter-Domain Routing (idr) |
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. |
| | 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. |
| | Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) |
| |
| | draft-ietf-lake-authz-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Goeran Selander, John Mattsson, Malisa Vucinic, Geovane Fedrecheski, Michael Richardson |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. |
| | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | 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. In order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use 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, this document defines a set of well-known EDHOC application profiles. |
| | Remote attestation over EDHOC |
| |
| | draft-ietf-lake-ra-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Yuxuan Song, Goeran Selander |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
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. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure and CMS |
| |
| | draft-ietf-lamps-pq-composite-sigs-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. |
| | Layer-3 Discovery and Liveness |
| |
| | draft-ietf-lsvr-l3dl-14.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Randy Bush, Rob Austein, Russ Housley, Keyur Patel |
| | Working Group: |
Link State Vector Routing (lsvr) |
|
In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. |
| | DLEP DiffServ Aware Credit Window Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. |
| | QUIC-Aware Proxying Using HTTP |
| |
| | draft-ietf-masque-quic-proxy-05.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Tommy Pauly, Eric Rosenberg, David Schinazi |
| | Working Group: |
Multiplexed Application Substrate over QUIC Encryption (masque) |
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. |
| | DNS Configuration for Proxying IP in HTTP |
| |
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. |
| | More Instant Messaging Interoperability (MIMI) using HTTPS and MLS |
| |
| | draft-ietf-mimi-protocol-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Richard Barnes, Matthew Hodgson, Konrad Kohbrok, Rohan Mahy, Travis Ralston, Raphael Robert |
| | Working Group: |
More Instant Messaging Interoperability (mimi) |
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. |
| | IETF Community Moderation |
| |
|
The IETF will treat people with kindness and grace, but not endless patience. This document describes the creation of a moderator team for all the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-12.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. This solution document specifies In-stack network action and In-stack data specific requirements found in "Requirements for MPLS Network Actions". This document follows the architectural framework for the MNA technologies specified in "MPLS Network Actions (MNA) Framework". |
| | Supporting In Situ Operations,Administration and Maintenance Using MPLS Network Actions |
| |
| | draft-ietf-mpls-mna-ioam-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Rakesh Gandhi, Greg Mirsky, Tony Li, Haoyu Song, Bin Wen |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information using, for example, Preallocated or Incremental IOAM Option, that can be used to calculate various performance metrics. RFC 9326 defined the IOAM Direct Export (IOAM-DEX) Option in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the MNA mechanisms to collect and transport the on-path operational state, and telemetry information IOAM data fields, including IOAM-DEX Option. |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-20.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enable higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | NETCONF Extension to support Trace Context propagation |
| |
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. |
| | RESTCONF Extension to Support Trace Context Headers |
| |
|
This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. |
| | YANG Packages |
| |
|
This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. It describes how packages: are represented on a server, can be defined in offline YANG instance data files, and can be used to define the content schema associated with YANG instance data files. |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | Semantic Metadata Annotation for Network Anomaly Detection |
| |
|
This document explains why and how semantic metadata annotation helps to test, validate and compare Outlier and Symptom detection, supports supervised and semi-supervised machine learning development, enables data exchange among network operators, vendors and academia and make anomalies for humans apprehensible. The proposed semantics uniforms the network anomaly data exchange between and among operators and vendors to improve their Service Disruption Detection Systems. |
| | An Experiment: Network Anomaly Lifecycle |
| |
|
Network Anomaly Detection is the act of detecting problems in the network. Accurately detect problems is very challenging for network operators in production networks. Good results require a lot of expertise and knowledge around both the implied network technologies and the connectivity services provided to customers, apart from a proper monitoring infrastructure. In order to facilitate network anomaly detection, novel techniques are being introduced, including programmatical, rule-based and AI-based, with the promise of improving scalability and the hope to keep a high detection accuracy. To guarantee acceptable results, the process needs to be properly designed, adopting well-defined stages to accurately collect evidence of anomalies, validate their relevancy and improve the detection systems over time, iteratively. This document describes a well-defined approach on managing the lifecycle process of a network anomaly detection system, spanning across the recording of its output and its iterative refinement, in order to facilitate network engineers to interact with the network anomaly detection system, enable the "human-in-the-loop" paradigm and refine the detection abilities over time. The major contributions of this document are: the definition of three key stages of the lifecycle process, the definition of a state machine for each anomaly annotation on the system and the definition of YANG data models describing a comprehensive format for the anomaly labels, allowing a well-structured exchange of those between all the interested actors. |
| | Considerations of network/system for AI services |
| |
| | draft-irtf-nmrg-ai-deploy-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Yong-Geun Hong, Joo-Sang Youn, Seung-Woo Hong, Pedro Martinez-Julia, Qin WU |
| | Working Group: |
Network Management (nmrg) |
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, AI technology is changing from running only on very high performance servers to commodity servers with small affordable hardware, including microcontrollers, low performance CPUs, and AI chipsets. This document considers how to configure the network and system in terms of AI inference service to provide AI service in a distributed manner. It also describes the points to consider in the environment where a client connects to a cloud server and an edge device and requests an AI service. Some use cases of deploying network-based AI services, such as self-driving vehicles and network digital twins, are described.? |
| | 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. |
| | 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. |
| | OAM for Service Programming with Segment Routing |
| |
|
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. |
| | 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 SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| | 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. |
| | PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER |
| |
|
This draft specify a new mechanism where PCE allocates the BIER information centrally and uses PCEP to distribute them to all nodes, then PCC generate a "Bit Index Forwarding Table"(BIFT). |
| | PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE |
| |
|
This draft specify extensions to PCEP protocol when a PCE-based controller is responsible for allocates the BIER-TE information(BIER subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc), then PCC generate a "Bit Index Forwarding Table"(BIFT). |
| | DC aware TE topology model |
| |
|
This document proposes the extension of the TE topology model for including information related to data center resource capabilities. |
| | A UDP-based GMA (Generic Multi-Access) Protocol |
| |
|
A device can simultaneously connect to multiple access networks, e.g., Wi-Fi, LTE, 5G, DSL, and SATCOM (Satellite Communications). It is desirable to seamlessly combine multiple connections over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built-in multi- path capabilities. This document presents a new convergence protocol for managing data traffic across multiple network paths. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations to experiment with the protocol. |
| | EVPN Fast Reroute |
| |
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| | A CoRIM Profile for Arm's Platform Security Architecture (PSA) |
| |
|
PSA Endorsements include reference values, endorsed values, cryptographic key material and certification status information that a Verifier may need in order to appraise attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. |
| | SMTP Enhanced Status Codes for Potentially Unwanted Mail |
| |
|
We define a method by which an SMTP receiver can immediately notify a sender that their message is suspected to be unwanted, although it may still be accepted. |
| | IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension |
| |
|
This document defines the IKEv2 Link Maximum Atomic Packet and Packet Too Big Extension to limit reassembly operations being performed by the egress security gateway. This extension enables an egress security gateway to notify its ingress counterpart that fragmentation is happening or that the received (and potentially reassembled) ESP packet is too big and thus cannot be decrypted. In both cases, the egress node provides Maximum Transmission Unit (MTU) information. Such information enables the ingress node to configure appropriately its Tunnel Maximum Transmission Unit - also designated as MTU or Tunnel MTU (TMTU) - to prevent fragmentation or too big packets to be transmitted. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| | dry-run DNSSEC |
| |
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in a DS record, referred to as dry-run DS, signal to validating resolvers that dry-run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of a dry- run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. |
| | Ethernet VPN Virtual Private Wire Services Gateway Solution |
| |
|
Ethernet Virtual Private Network Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. |
| | Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) |
| |
|
As operators migrate from an IPv4 core to an IPv6 core for global table routing over the internet, the need arises to be able provide routing connectivity for customers IPv4 only networks. This document provides a solution called 4Provider Edge, "4PE" that connects IPv4 islands over an IPv6-Only network. |
| | More Instant Messaging Interoperability (MIMI) Identity Concepts |
| |
|
This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. |
| | SCION Control Plane PKI |
| |
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture where the Control Plane 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 provisions SCION's trust model based on Isolation Domains. This document describes the trust model behind the SCION Control Plane PKI, including specifications of the different types of certificates and the Trust Root Configuration. It also specifies how to deploy the Control Plane PKI infrastructure. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
| |
| | draft-eckert-detnet-tcqf-07.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren, Fan Yang |
| | Working Group: |
Individual Submissions (none) |
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. |
| | NTRU Key Encapsulation |
| |
| | draft-fluhrer-cfrg-ntru-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Scott Fluhrer, Michael Prorock, Sofia Celi, John Gray, Xagawa Keita, Haruhisa Kosuge |
| | Working Group: |
Individual Submissions (none) |
|
This draft document provides recommendations for the implementation of a post-quantum Key Encapsulation Mechanism (KEM) scheme based on the NTRU encryption scheme. The KEM is an existing cryptographic system; no new cryptography is defined herein. The well-defined and reviewed parameter sets for the scheme are defined and recommended. The test vectors are also provided. |
| | Scenarios and Protocol Extension Requirements of a Generalized IPv6 Tunnel |
| |
|
IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Network Slicing, Alternate Marking, iOAM, DetNet etc. In some networks, the operators might want to leverage these new features but since the network system still using some lagecy encapsulations other than IPv6 (e.g. VxLAN, GRE etc.), these features are just not applicable for them. This document introduces some cases of such scenarios, and discusses the potential requirement of defining a new Generalized IPv6 Tunnel (GIP6). With GIP6, all the additional functions defined as IPv6 extension headers could be easily supported, so that the legacy encapsulations could migrate to a unified solution rather than sccaterred upgrade in each legacy technologies, which is heavy burden for the industry. Considering network devices have different capabilities of IPv6 extension header processing, this document also analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. |
| | 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. |
| | The "dereferenceable identifier" pattern |
| |
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. // The present revision -04 includes a few clarifications. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | the extensions of BGP-LS to carry security capabilities |
| |
|
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. |
| | 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 trusted mirrors 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. |
| | 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. |
| | 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 topological elements 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). |
| | 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). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
| |
| | draft-eckert-detnet-glbf-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| | Working Group: |
Individual Submissions (none) |
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. |
| | BGP SR Policy Extensions for Path Scheduling |
| |
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios. This document proposes extensions to BGP SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes. |
| | Crowd Sourced Remote ID |
| |
|
This document describes a way for an Internet connected device to forward/proxy received Broadcast Remote ID into UAS Traffic Management (UTM). This is done through a Supplemental Data Service Provider (SDSP) that takes Broadcast Remote ID in from Finder and provides an aggregated view using Network Remote ID data models and protocols. This enables more comprehensive situational awareness and reporting of Unmanned Aircraft (UA) in a "crowd sourced" manner. |
| | Packed CBOR: Table set up by reference |
| |
|
Packed CBOR is a mechanism for transforming Concise Binary Object Representation (CBOR) data into a more compact form. This document introduces a means for setting up its tables by means of dereferenceable identifiers, and introduces a pattern of using it without sending long identifiers. |
| | Email Feedback Reports for DKIM Signers |
| |
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. |
| | 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 role 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 provides a detailed specification of the SCION data packet format as well as the structure of the SCION header. SCION also supports extension headers, which are additionally described. The document continues with the life cycle of a SCION packet while traversing the SCION Internet, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | IGP Flexible Algorithm with Link Loss |
| |
|
This document proposes extensions to the IGP Flexible Algorithms framework defined in [RFC9350]. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link loss measurements advertised via IS-IS [RFC8570] and OSPF [RFC7471], and defines new constraints for Flex-Algorithm path calculation. |
| | Enhanced Use Cases for Scaling Deterministic Networks |
| |
|
This document describes use cases and network requirements for scaling deterministic networks which is not covered in RFC8578, such as industrial internet, high experience video, intelligent computing, and ISAC-enabled smart factory and outlines the common properties implied by these use cases. |
| | Proposed Update to BGP Link-State SPF NLRI Selection Rules |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. |
| | 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 authors (gratefully) accept pull requests. |
| | IKEv2 support for specifying a Delete notify reason |
| |
|
This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). |
| | RTP Payload Format for Geometry-based Point Cloud Compression |
| |
|
This memo describes an RTP payload format for geometry-based point cloud compression (G-PCC) ([ISO.IEC.23090-9]). The RTP payload format defined in this document supports the packetization of one or more data units in an RTP packet payload and the fragmentation of a single data unit into multiple RTP packets. This memo also describes congestion control for a practical solution for the real-time streaming of point clouds. Finally, the document defines parameters that may be used to select optional features of the payload format or signal properties of the RTP stream. The parameters can be used with the Session Description Protocol (SDP). |
| | Path Computation Based on Precision Availability Metrics |
| |
| | draft-contreras-pce-pam-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Luis Contreras, Fernando Agraz, Salvatore Spadaro, Quan Xiong |
| | Working Group: |
Individual Submissions (none) |
|
The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. |
| | Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document defines a usage of Datagram Transport Layer Security (DTLS) 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP DTLS chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with in-band DTLS based key-management and mutual authentication of the peers. The specification is enabling very long-lived sessions of weeks and months and supports mutual re- authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP (RFC6083) and SCTP-AUTH (RFC4895). |
| | Stream Control Transmission Protocol (SCTP) DTLS Chunk |
| |
|
This document describes a method for adding Cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP DTLS chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using SCTP DTLS chunk can use all transport features provided by SCTP and its extensions but with some limitations. |
| | Safe(r) Limited Domains |
| |
|
Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks. |
| | Stand-in Tags for YANG-CBOR |
| |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. |
| | 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. |
| | 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 settings for the Perfect Forward Secrecy (PFS) and which Key Exchange (KE) method(s) setting of the initial Child SA that are expected to be used during Child SA rekey. |
| | 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. |
| | Discovery of Network-designated OSCORE-based Resolvers: Problem Statement |
| |
| | draft-lenders-core-dnr-05.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. |
| | SAVNET Use Cases |
| |
| | draft-ys-savnet-use-cases-02.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | Light MLS |
| |
| | draft-kiefer-mls-light-02.txt |
| | Date: |
03/03/2025 |
| | 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 costs, especially when joining a group. This document defines an MLS extension to support "light clients" that don't undertake these costs. 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. |
| | STI Certificate Transparency |
| |
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). |
| | Self-Clocked Rate Adaptation for Multimedia |
| |
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR googles. This specification obsoletes RFC 8298. |
| | 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. |
| | GMA Traffic Splitting Control |
| |
| | draft-zhu-gma-tsc-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jing Zhu, Menglei Zhang, Sumit Roy |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the GMA (Generic Multi-Access) traffic splitting control algorithm. The receiving endpoint measures one- way-delay, round-trip time, and delivery rate for multiple connections and determines how a data flow is split across them. When update is needed, it will send out a control message, aka Traffic Splitting Update (TSU), to notify the transmitting endpoint of the new traffic splitting configuration. Compared to other sender-based multi-path transport protocols, e.g. MPTCP, MPQUIC, the GMA traffic splitting algorithm is receiver-based and does not require per-packet feedback, e.g. Ack. It is designed specifically to support the Generic Multi-Access (GMA) convergence protocol as introduced in [MAMS] [GMA]. The solution has been developed by the authors based on their experiences in multiple standards bodies including IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | Representing metadata annotations in YANG-CBOR |
| |
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| | Problem statements and requirements of Deterministic CATS on the Industrial Internet |
| |
|
This draft illustrates use cases of traffic steering for Industrial Internet in terms of dynamic computing and networking resource status,together with the requirements and solutions for CATS(Computing-Aware Traffic Steering).Industrial production tasks are time-sensitive, which put forward high requirements on collaboration of networks and applications. Industrial management platforms need to unify network forwarding and computing tasks at the same time. |
| | Bgp Extension for Tunnel Egress Point |
| |
|
In AI networks, flow characteristics often exhibit a low number of flows but with high bandwidth per flow, making it easy to cause network congestion when using traditional flow-level load balancing methods. Currently, the direction of traffic scheduling focuses on load sharing individual packets of the same flow, which requires sorting based on the Tunnel Egress Point information from the remote end. This document describes the method of publishing Tunnel Egress Point through the BGP protocol. |
| | Filter of Configuration Change Notifications |
| |
|
This document extends the YANG-Push notification subscription mechanism for on-change to reduce unnecessary reporting after an on- change YANG-Push notification is generated. |
| | Arm's Confidential Compute Architecture Reference Attestation Token |
| |
|
The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. |
| | Arm's Confidential Computing Architecture (Arm CCA) Attestation Verifier Endorsements |
| |
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an Arm CCA system. 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/yogeshbdeshpande/draft-cca-rats-endorsements. |
| | Pacing in Transport Protocols |
| |
| | draft-welzl-iccrg-pacing-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | Network Attestation for Secured foRwarding (NASR) Architecture |
| |
|
This document provides an architecture overview of NASR entities, interactive procedures and messages. |
| | YANG Data Model for Power-Group Aware TE Topology |
| |
|
This document discusses the notion of a Power-Group construct as an attribute of a Traffic Engineered (TE) Link and defines a YANG data model for representing a Power-Group aware TE topology. |
| | Challenge: Network Digital Twin - Practical Considerations and Thoughts |
| |
|
This document focuses on practical challenges associated with the design, creation and use of Network Digital Twins. According to the identified challenges, a set of suitable functional elements are described to overcome some of these challenges. Experiences from the design, development and evaluation of an SDN-based Network Digital Twin are described and conclude this document. |
| | Mobile Traffic Steering |
| |
| | draft-liebsch-dmm-mts-02.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Individual Submissions (none) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. Two architectural principles are described and discussed in the view of existing or new IETF technology that enables end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers |
| |
|
Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. |
| | A Top-level Domain for Private Use |
| |
|
This document describes the "internal" top-level domain for use in private applications. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
This document specifies an extension to the ACME protocol [RFC8555] that enables ACME servers to use the public key authentication protocol to verify the certificate applicant's control of the identity and to ensure strong consistency between the final certificate issued and the identity of the application order. A process extension for removing CSR at the certificate application phase is also proposed in this document. |
| | MASQUE extension for signaling throughput advice |
| |
|
This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for traffic that is proxied through an HTTP server. |
| | LSP State Reporting Extensions in Path Computation Element Communication Protocol (PCEP) |
| |
|
The Path Computation Element Communication Protocol (PCEP) is defined in multiple RFCs for enabling communication between Path Computation Elements (PCEs) and Path Computation Clients (PCCs). Although PCEP defines various LSP identifiers, attributes, and constraints, there are operational attributes available on the PCC that can enhance path computation and improve the debugging experience, which are not currently supported in PCEP. This document proposes extensions to PCEP to include: * Support for explicit or dynamic path types * Mechanisms to mark LSPs as eligible for use as transit LSPs * Allowing instantiation of LSP and optionally do fallback to Binding label/Segment Identifier (SID) allocation by the PCC when the binding value specified by the PCE is unavailable These extensions aim to address the existing gaps, enhancing the overall functionality and operational efficiency of PCEP. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ TLS 1.3. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
| | draft-liu-acme-rats-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide a Remote Attestation Evidence or Remote Attestation Result in any format supported by the Conceptual Message Wrapper. The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | Populating a list of YANG data nodes using templates |
| |
|
This document presents a modeling technique for configuring large scale devices in a compact way, when the device contains many similar data node patterns. A device here refers to any such entity that acts as a netconf server. This is realized by instructing the device to locally generate repetitive patterns of data nodes from a master copy called 'template' that is configured in the device. This approach is both convenient and efficient, as it minimizes the size of the running data store and reduces network provisioning time. It leverages existing YANG specification features and can be implemented with standard, off-the-shelf tools.The concept that is described in this draft does not aim to be a standard track document and does not cover the template solution that is currently being discussed within ietf netmod. |
| | Calibration of Measured Time Values between Network Elements |
| |
|
Network devices are incorporating capabilities for time stamping certain packets so that such time stamps can reference the time at which a packet passes through a given device (at ingress or egress). Those stamps or marks are relevant to calculating the measured delay and can be used for traffic engineering purposes. This draft proposes a methodology for Calibrating the measurements from different network element implementations in a common measurement scenario. |
| | DKIM2 Why DKIM needs replacing,and what a replacement would look like |
| |
|
This memo provides a rationale for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. |
| | Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness |
| |
|
When an IPv6 prefix assigned to a link changes, hosts may not be explicitly notified about the change. Similarly, in some scenario a link attachement for the host may change without the host detecting it. In both cases the host does not receive any signals to trigger the network stack configuration refresh, so it may continue to use "old" addresses which are not valid for the link. This leads to packet loss and service disruption. This document proposes a mechanism to mitigate this issue. Routers are advised to send Router Advertisements containing distinct Prefix Information Options (PIOs) from different link-local addresses. This, in conjunction with RFC6724 (Default Source Address Selection) Rule 5.5 and RFC8028 (first-hop selection requirements), enables hosts to detect prefix changes more rapidly and select the correct source address, thereby improving the robustness of SLAAC. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication ( SIG(0) ) |
| |
|
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based authentication of DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931. |
| | DHCP Option Concatenation Considerations |
| |
|
DHCP has a length limit of 255 on individual options because of its one-byte length field for options. To accommodate longer options, splitting option data across multiple instances of the same Option Type is defined by RFC 3396. However, this mechanism was defined to require support for all option types. This has led to real-world implementations in the years since the RFC was published to deviate from these requirements to avoid breaking basic functionality. This document updates RFC 3396 to be more flexible regarding when DHCP agents are required to concatenate options to reflect deployement experiences. |
| | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
|
This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP control plane elements generically called "DDT Nodes". Each DDT Node is configured as "authoritative" for one or more EID-Prefixes, along with the set of RLOCs for Map-Servers or "child" DDT Nodes to which more-specific EID-Prefixes are delegated. This document obsoletes RFC 8111 and updates RFC 9301. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method of advertising SRv6 locator to neighboring SRv6 Segment Endpoint nodes through IPv6 Neighbor Discovery protocol. |
| | Problem Statement about IPv6 Support for Multiple Routers,Multiple Interfaces,and Multiple Prefixes |
| |
|
This document discusses current limitations in IPv6 Stateless Address Auto-configuration (SLAAC) that prevent support for common multi- router, multi-interface, and multi-prefix scenarios. It provides discussion on the challenges that these scenarios represent, and why a solution in this space is warranted. Finally, it specifies a number of common scenarios that any solution in this space should be able to address. |
| | Current State of the Art for Routing in AI Networks |
| |
|
This document provides an overview of routing technologies that address the needs of traffic engineering and load balancing, with a focus on fast notification for example in adaptive or perceptive routing. As the scale and complexity of networks grow, these technologies are becoming increasingly important when fault tolerance and rapid convergence are critical. This document explores existing solutions from both the IETF and the broader industry, highlighting their applicability to various use cases, including AI workloads and general services that demand low-latency, fault recovery, and dynamic load distribution across data center networks and inter data center. It also offers suggestions for potential IETF initiatives to further develop and standardize these techniques. |
| | Documenting and Referencing Cryptographic Components in IETF Documents |
| |
|
This document describes the history of how cryptographic components have been documented and referenced in the IETF, such as in RFCs, Internet Drafts, and exernal sources. It also gives guidance for how such specification should happen in the future. %% (To be removed before publication as an RFC) This document is being developed in SAAG. There is a git repo for the document at https://github.com/paulehoffman/draft-paulwh-crypto-components (https://github.com/paulehoffman/draft-paulwh-crypto-components). %% |
| | Microservice Communication Resource Scheduling for Distributed AI Model |
| |
|
This document describes the architecture of microservice communication resource scheduling for distributed AI model. |
| | Dynamic Trust Security Architecture for Distributed Service Mesh |
| |
|
This document proposes a dynamic trust security architecture based on Distributed Micro Service Communication (DMSC) to address the security risks in the communication of microservices. The DMSC architecture, by leveraging content semantic routing and decentralized control, transforms the traditional host-centric communication mode into a service-centric paradigm. Although DMSC enhances scalability and flexibility, its distributed nature introduces risks. To cope with these risks, it is necessary to consider security solutions for distributed large-scale microservice communication and ensure the security of services while minimizing the impact on the communication architecture. |
| | Improving Support for Multi-Router,Multi-Interface,and Multi-Prefix Scenarios |
| |
|
This document specifies a improvements to IPv6 Stateless Address Autoncofiguration (SLAAC) to fully support common multi-router, multi-interface, and multi-prefix scenarios. It formally updates RFC 4191, RFC 4861, RFC 4862, and RFC 8504, RFC 8028, and RFC 6724, such that these scenarios are properly supported by IPv6 host implementations. |
| | WIMSE Credential Exchange |
| |
|
WIMSE defines Workload Identity and its representation through credentials. Typically, a credential is provisioned to the workload, allowing it to represent itself. The credential format is usually chosen by the platform. Common formats are JSON Web Tokens or X.509 certificates. However, workloads often encounter situations where a different identity or credential is required. This document describes various situations where a workload requires another credential. It also outlines different ways this can be acchieved and compares them. |
| | Export of Path Segment Identifier Information in IPFIX |
| |
|
This document introduces a new IPFIX Information Element to identify the Path Segment Identifier(PSID) in the SRH for SRv6 path identification purpose. |
| | COSE Algorithms for Two-Party Signing |
| |
|
This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited- bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data. |
| | Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF |
| |
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI. |
| | Power and Energy Efficiency |
| |
| | draft-pslm-poweff-01.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Jan Lindblad, Snezana Mitrovic, Marisol Palmero, Gonzalo Salgueiro |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a device YANG "dashboard" data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in the form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else. |
| | RPKI Terminology |
| |
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times beinconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for high-speed data transmission in High Performance Wide Area Network (HP-WAN). It particularly facilitates the functionalities of the edge nodes/gateway nodes/proxy to transform transport protocols and collaborate with the host to perform QoS negotiation, such as flow control, admission control and traffic scheduling. |
| | Lightweight Host Routing using LLDP |
| |
|
Link Layer Discovery Protocol (LLDP) is widely deployed today for discovery of information across network elements like routers, switches, and hosts. This document extends LLDP to allow hosts to advertise their IP prefixes to their attached routers which can then propagate the reachability of these host prefixes into routing protocols for enabling network-wide connectivity. |
| | IS-IS Extensions for Load Balancing Alternates |
| |
|
IGP normally computes the shortest paths in the network based on the IGP metric, without taking the link utilization into consideration. In network scenarios where there is link degradation or failure which causes link throughput reduction, or the volume of specific traffic flows increase dramatically, congestion can happen if only the best path is used for forwarding. This document describes IS-IS extensions for the computation of alternate traffic engineering paths which can be used for traffic load balancing when the shortest path is becoming congested. |
| | Adapting Home Routers to Congestion Control's Reactions for Consistent Low Latency |
| |
|
This document describes Confucius -- a practical queue management scheme designed for offering real-time flows with consistently low latency regardless of competition. Confucius employs an age-aware weight adjustment mechanism to slows down bandwidth adjustment to match the reaction of congestion control, so that the end host can reduce the sending rate without overshooting the network. Confucius is deployed on home routers and requires no configuration in normal Internet deployments. |
| | IPv6 Network Deployment Monitoring and Analysis |
| |
|
This document proposes an IPv6 network end-to-end monitoring and analysis framework. The aim is to address key issues existing in current IPv6 deployment monitoring, such as limited coverage, insufficient depth of analysis, and lack of cross-domain collaboration. |
| | SPICE Use Cases in Telecom Network |
| |
|
This document describes use cases of the credential specific to the telecom network. It aims to propose benefits and scenarios regarding to introducing the credential to the telecom network, which can provide more scenarios and directions to Secure Patterns for Internet CrEdentials (SPICE) specifications. |
| | Clarifications to the DNS Ranking Data |
| |
|
This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181, and specifies directives whereby the source of the data determines for what purposes it may be used. |
| | Automatic Network Congestion Relief |
| |
|
This document introduces an automatic congestion relief mechanism based on intelligent traffic analysis and dynamic regulation. In the event of congestion caused by fiber optic failures, it can respond intelligently and self-heal in real time, ensuring the stable operation of the network. |
| | Fast Reroute based on Programmable Data Plane (PDP-FRR) |
| |
| | draft-li-fantel-pdp-frr-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Dan Li, Kaihui Gao, Shuai Wang, Li Chen, Xuesong Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document introduces a fast reroute architecture within the programmable data plane (PDP-FRR) for enhancing network resilience through rapid failure detection and swift path migration, leveraging in-band network telemetry and source routing. Unlike traditional methods that rely on the control plane and face significant delays in rerouting, the proposed architecture utilizes a white-box modeling of the data plane to distinguish and analyze packet losses accurately, enabling immediate identification for link failures (including black- hole and gray failures). By utilizing in-band network telemetry and source routing, the proposed solution significantly reduces reroute times to a few milliseconds, offering a substantial improvement over existing practices and marking a pivotal advancement in failure tolerance. |
| | Encryption of SRv6 Function in SRv6 Network |
| |
|
This document describes an encryption mechanism for the SRv6 function in the SRv6 nodes. |
| | A Public Key Service Provider for Verification in Multiple Issuers and Verifiers |
| |
|
SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure. |
| | Requirements and Deployments for High-Speed IoV based on SRv6 |
| |
|
This document proposes a deployment scheme for high-speed IoV by utilizing CATS, IFIT, SRv6, and network slicing technologies. Requirements and problems are discussed, and a deployment scheme is described in detail. |
| | ACK Frequency Adjustment in Receiver |
| |
|
This document describes a mechanism for adjusting ACK frequency in the receiver. |
| | Extensible YANG Model for Network Telemetry Notifications |
| |
|
This document defines an extensible message schema in YANG to be used at the data collection for transforming Network Telemetry notifications into external systems such as message brokers. The extensible message schema enables a data collection to add metadata for the provenance of the operational network data. |
| | JWTClaimConstraints profile of ACME Authority Token |
| |
|
This document defines an authority token profile for handling the validation of JWTClaimConstraints and Enhanced JWTClaimConstraints. This profile follows the model established in Authority Token for the validation of TNAuthList but is specifically tailored for the JWTClaimConstraints certificate extensions. The profile enables validation and challenge processes necessary to support certificates containing both TNAuthList and JWTClaimConstraints, particularly in the context of Secure Telephone Identity (STI). |
| | Synchronizing BMP Monitoring Options and State |
| |
|
This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector. |
| | Requirements Analysis of System and Network for Large Language Model Inference Service |
| |
|
With the rise of ChatGPT, DeepSeek, and other Large Language Models, which is short for LLMs in the remaining part, as well as the proliferation of inference applications, inference serving oriented to large-scale users has become increasingly critical. However, due to the extreme demands on computing power and communication during inference, the large-scale service deployment of LLMs poses significant challenges. To address these challenges, different vendors have adopted diverse inference service architectures, among which the vLLM proposed in 2023 is the most representative. This paper investigates mainstream inference frameworks, summarizes their core design principles, and analyzes the requirements and challenges they impose on system and network configurations. The goal is to lay a foundation for defining a unified LLM inference architecture in the future. |
| | Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in SR |
| |
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in Segment Routing (SR) networks. By extending existing OAM mechanisms such as ping, traceroute, Bidirectional Forwarding Detection (BFD), and Simple Two-way Active Measurement Protocol (STAMP), the proposed solution enables comprehensive NRP support in SR networks. |
| | Interface to In-Network Computing Functions (I2ICF): Problem Statement |
| |
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. |
| | A Framework for LLM-Assisted Network Management with Human-in-the-Loop |
| |
|
This document defines an interoperable framework that facilitates collaborative network management between Large Language Models (LLMs) and human operators. The proposed framework introduces enhanced telemetry module, LLM decision module and standardized interaction data models between human operators and LLM-driven systems, and workflows to enforce human oversight. The approach ensures compatibility with existing network management systems and protocols while improving automation and decision-making capabilities in network operations. |
| | A Framework for the Interface to In-Network Computing Functions (I2ICF) |
| |
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. |
| | Interfaces of In-Network Computing Functions in Data Center Networking |
| |
|
In-network computing has gained a lot of attention and been widely investigated as a research area in the past few years, due to the exposure of data plane programmability to application developers and network operators. After several years of trials and research, some of in-network computing capabilities, or to say In-Network Computing Functions (ICF) have been proved to be effective and very beneficial for networked systems and applications, like machine learning and data analysis, and these capabilities have been gradually commercialized. However, there still lacks a general framework and standardized interfaces to register, configure, manage and monitor these ICFs. This document focuses on the applicability of ICFs in a limited domain in [RFC8799], e.g., data center networks, and describes a framework for orchastrating, managing, and monitoring these ICFs. |
| | libZK: a zero-knowledge proof library |
| |
|
This document defines a technique for generating a succinct non- interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0. |
| | Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems |
| |
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) in Cooperative Intelligent Transportation Systems (C-ITS). For example, in the context of Vehicle-to-Everything (V2X) communications, efficient management of Vehicle-to-Vehicle (V2V) communications and their integration with C-ITS can greatly benefit from in-network computing. By leveraging ICFs, it becomes possible to optimize real- time communication, streamline traffic management, and enhance data processing and security services at the network edge. |
| | Large Model based Agents for Network Operation and Maintenance |
| |
|
Current advancements in AI technologies, particularly large models, have demonstrated immense potential in content generation, reasoning, analysis and so on, providing robust technical support for network automation and self-intelligence. However, in practical network operations, challenges such as system isolation and fragmented data lead to extensive manual, repetitive, and inefficient tasks, the improvement of intelligence level is very necessary. This document identifies typical scenarios requiring enhanced intelligence, and explains how AI Agents and large model technologies can empower networks to address operational pain points, reduce manual efforts, and explore impacts on network data, system architectures, and interfaces correspondingly. It further explores and summarizes standardization efforts in implementation. |
| | Source Address Validation Deployment Status |
| |
|
This document provides a summary of methods for measuring the deployment status of source address validation, with an overview of its deployment status. It reviews various methods for measuring outbound and/or inbound source address validation, including established tools like CAIDA Spoofer, as well as recently proposed remote measurement methods. By combining results from these different methods, the document offers a comprehensive overview of the status of source address validation deployment across the Internet. |
| | Remote Attestation MultiVerifier |
| |
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. 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/ietf-rats/draft-deshpande-multi-verifier. |
| | YANG Datastore Telemetry (YANG Push Lite) |
| |
|
YANG Push Lite is a YANG datastore telemetry solution, as an alternative specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. |
| | Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. |
| | QUIC NAT |
| |
|
QUIC uses UDP as its transport layer protocol. Many existing NAT routers rely on observing TCP SYN, ACK, and FIN packets to determine the establishment and termination of connections, thereby precisely maintaining the lifecycle of NAT mapping entries. For QUIC, NAT devices can only manage mapping entries based on ordinary UDP aging mechanisms, which may cause NAT entries for long-lived QUIC connections to be prematurely aged and re-bound, resulting in changes to source ports. This document proposes a solution that extends the IP header options field to identify QUIC connections, facilitating NAT devices that do not recognize QUIC to accurately determine the lifecycle of QUIC connections and prevent random aging and re-mapping of long-lived QUIC connections. |
| | Congestion Detection Optimization |
| |
|
This draft proposes an adaptive congestion detection mechanism for high-throughput data transmission in wide area networks (WANs). With increasing network bandwidth (up to 800Gbps) and challenges in traditional TCP-based protocols (e.g., throughput degradation over long distances and high packet loss rates), the solution focuses on optimizing congestion identification while minimizing bandwidth overhead. |
| | Default Policy and Related Metrics in CATS |
| |
|
This document describes the considerations and requirements of the computing information that needs to be notified into the network in Computing-Aware Traffic Steering (CATS). Especially, it suggests that a default policy should be supported on the Ingress, and one or more default metrics should be included in the notification. |
| | Adaptive Load Balance Enhancement |
| |
|
This draft proposes an adaptive load-balancing mechanism to address high-throughput transmission challenges in East-West computing, data exchange, and DC interconnection services. Traditional methods-ECMP, RPS, and Flowlet-face limitations: ECMP suffers from hash collisions and load imbalance; RPS risks TCP packet reordering; Flowlet depends on impractical manual thresholds for burst interval configuration, leading to suboptimal performance. |
| | KEM based Authentication for the IKEv2 with Post-quantum Security |
| |
|
This draft specifies a new authentication mechanism, called KEM based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. This is motivated by the fact that ML-KEM is much more efficient that ML-DSA, which are the post-quantum algoirhtms for mitigating the pontential security threats again quantum computers. The KEM based authenticationth for the IKV2 is achieved via introduing a new value of the IKEv2 Authentication Method registry mantained by IANA. For using the new authentication method, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined by [RFC9593]，to negotiate the supported KEM algorithms. After that, the correponding KEM certificates and cipthertext are exchanged via the INTERMEDIATE Exchange. Finally，the IKE messages are authenticated via the shared secret encapsulated between the two peers. This documents also specifies the instantiation with ML-KEM for this new general authenticaiton method for the IKEv2. [EDNOTE: Code points for KEM-based authentication may need to be assigned in the IKEv2 Authenticaion Method registry, maintained by IANA] |
| | SR-MPLS Aggregation Segment |
| |
|
One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. Contrary to this, MPLS forwarding works on exact match on MPLS labels. This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. This document introduces an Aggregation Segment for Segment Routing with MPLS data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks. |
| | Source Address Validation Using Source Address Authorizations (SOAs) |
| |
|
Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to validate the authenticity of source address of packets. Source Address Authorization (SOA) is a newly defined cryptographically signed object; it provides a means of recording information about the last Autonomous System (AS) traversed by packets before reaching a specific AS. When validated, the eContent of an SOA object confirms that the holder of the listed AS Number (ASN) has authorized the specified pre-ASes. This enables other ASes to collaboratively filter spoofed traffic, enhancing global Internet security by mitigating source address spoofing and DDoS attacks. |
| | Terminal 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 mobility management 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. |
| | Information Element for Flow Discard Classification |
| |
|
This document defines a new IPFIX Information Element for classifying flow-level discards which aligns with the information model defined in [I-D.ietf-opsawg-discardmodel]. The flowDiscardClass Information Element provides consistent classification of packet discards across IPFIX implementations, enabling correlation between device and interface-level statistics and impacted flows. |
| | BGP Flowspec Redirects to SR Policy |
| |
|
Flowspec, an extension to BGP, enables the dissemination of traffic flow specification rules and can be used to steer traffic into SR Policy. However, existing approaches using Flowspec to direct traffic into a SR Policy have certain drawbacks (for details, refer to section 1). This document difines two new standard actions for the BGP Flowspec V2 protocol (FSv2) [I-D.ietf-idr-flowspec-v2]: Redirect to SR Policy Action and SRv6 SID Action. The former allows traffic to be directed to a designated SR Policy, while the latter enables the encapsulation of an additional SRv6 SID as needed during redirection. These extensions address the shortcomings of existing solutions. |
| | Yang Data Model for supporting multipath IGMP/MLD proxies |
| |
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. |
| | Computing Energy Consumption Path in Segment Routing Networks |
| |
|
This document describes a method for computing energy consumption paths in Segment Routing (SR) networks, aiming to optimize network traffic routing for energy efficiency, including procedures for energy consumption data collection, path calculation, and issuance, as well as considerations for data plane implementation in both MPLS SR and SRv6 networks. |
| | PCEP extensions for energy consumption |
| |
|
[draft-liu-spring-sr-energy-consumption-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document further details the process of using the PCEP protocol for energy consumption based path requests. The Path Computation Element Communication Protocol (PCEP) provides mechanisms that enable Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs). This document describes the extension to PCEP for conveying link energy consumption and node energy consumption, allowing path computation based on these energy consumption information. |
| | Flexible Algorithms for Energy Efficiency |
| |
|
[draft-liu-spring-sr-policy-energy-efficiency-00] describes how energy consumption information is utilized for path selection in Segment Routing (SR) networks. This document elaborates on extending IGP protocols to carry energy consumption information, enabling its dissemination within the IGP domain and ultimately transmitting it to the controller. This allows the controller to perform routing calculations based on energy consumption metrics. |
| | BGP-LS extensions for energy efficiency |
| |
|
[draft-liu-spring-sr-policy-energy-efficiency-00] describes the types of energy consumption information, how to collect energy consumption information, and the framework for path selection based on energy consumption information. This document elaborates on extending BGP-LS to carry energy consumption information and transmit it to the controller, enabling the controller to perform routing calculations based on energy consumption metrics. |
| | Verifiable STI Persona (VESPER) Use Cases and Requirements |
| |
|
This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called VESPER (Verifiable STI PERsona). VESPER enhances STIR by incorporating a trust framework that associating a responsible business entity and/or human with the assignment and right-to-use a telephone number. Important to the use-cases and requirements are mechanisms for the preservation of privacy and explicit choice to reveal information beyond the communications service provider you have chosen to assign the telephone number with. Core to this premise is the ability to represent and prove the right to use a telephone number resource via the legitimate holder of the Vesper token. Additional metadata and attributes can be vetted and attested via vetting policies and Know- Your-Customer (KYC) processes that are not defined as part of this effort but should follow jurisdiction specific best practices and policies that may exist. The framework allows for the leveraging of trusted and identified issuers to create a signed credential known as a VESPER token that will be defined including associated claims and potential paths for extensibility in the future. In addition, transparency mechanisms are explored to provide public logs or registries of certificates, keys, entity information, or telephone number details, if desired by the telephone number holder to improve trustability, visibility and accountability within the telephone ecosystem. This document covers various scenarios in which VESPER can be used to enhance trust in communications, focusing on common real-world deployments and corresponding requirements. This work is intended to complement and align with the framework described currently as a work in progress in [I-D.wendt-stir-vesper]. |
| | RADIUS over QUIC |
| |
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. |
| | Transparent Rate Optimization for Network Endpoints (TRONE) Protocol |
| |
|
On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and what that rate limit is. |
| | Remote Attestation with Exported Authenticators |
| |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. This approach falls into the category of post-handshake attestation by exchanging payloads in the application layer protocol while binding the remote attestation to the underlying communication channel. This document supports both the passport and background check models from the RATS architecture. |
| | Artificial Intelligence (AI) for Network Operations |
| |
|
This document explores the role of the IETF and IRTF in advancing Artificial Intelligence for network operations (AINetOps), focusing on requirements for IETF protocols and architectures. AINetOps applies AI/ML techniques to automate and optimize network operations, enabling use cases such as reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance. The document addresses AINetOps for both single-layer IP or Optical networks and multi-layer IP/Optical networks. It defines the concept of AINetOps for networking and provides its operational benefits such as network assurance, predictive analytics, network optimization, multi-layer planning, and more. It aims to guide the evolution of IETF protocols to support AINetOps-driven network management. |
| | Multipath Traffic Engineering |
| |
| | draft-kompella-teas-mpte-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Kireeti Kompella, Luay Jalil, Mazen Khaddam, Andy Smith |
| | Working Group: |
Individual Submissions (none) |
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, nor the load balancing equally weighted to each next hop. Moreover, the desired destination may be reachable via multiple egresses. The proposal includes a protocol for signaling MPTE paths using various types of tunnels, some of which are better suited to multipathing. |
| | Extensible Delegation for DNS using different transport protocols |
| |
|
This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in [I-D.draft-wesplaap-deleg], with ability to specify transport protocols and authentication parameters supported by name servers. |
| | BGP SR Policy Extensions for Performance-Aware Path Selection |
| |
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute [RFC9012]. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in [RFC4271], modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec |
| |
|
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information, and. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | DKIM2 Header Definitions |
| |
|
This document describes the headers defined for DKIM2 and how they work togther to provide the behaviours that are designed into DKIM2. This is an early draft, a work in progress. |
| | Signaling Zone Owner Intent |
| |
|
This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines a new DNS RRtype, HSYNC (Horizontal Synchronization), that enables zone owners to designate which providers are authorized to serve and/or sign their zones, control whether providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC record allows DNS providers to discover each other and establish secure communication channels, either via DNS messages secured by SIG(0) signatures or via a RESTful API secured by TLS. This provider-to-provider communication via Agents enables automated coordination for tasks such as NS RRset management, zone transfers, and DNSSEC-related operations. This specification covers the provider discovery and communication establishment aspects. The document defines two new roles to facilitate this synchronization: the Agent responsible for provider-to-provider communication and the Combiner which merges unsigned zone data from the zone owner with managed data from providers. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in RFC8901) is an important application of this framework, the HSYNC mechanism supports broader provider synchronization needs. The specific synchronization algorithms for multi-signer operation are described in [I-D.draft-ietf-dnsop-dnssec-automation]. Specification for how to express these algorithms over provider-to- provider communication is left for a follow-up document. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Guidance for Authors writing text for the BGP Tunnel Encapsulation Attribute |
| |
|
The BGP (RFC4271) Tunnel Encapsulation Attribute (TEA) is defined in RFC9012. Currently proposed BGP specifications in the IDR and BESS Working groups have defined new tunnels and new parameters for these tunnels in Sub-TLV. The Segment Routing usage of the TEA has suggested a number of new Sub-TLVs. This document provides guidelines to help authors quickly write correct text for new tunnels (defined in tunnel TLVs) and new Sub-TLVs. These guidelines are given as "templates" to aid new authors. More experience authors should view these templates as a list of expected content. One additional challenge for tunnels using the PMSI tunnels is to carefully define the interaction between PMSI tunnels and TEA tunnels. |
| | An IETF URN Sub-Namespace for JSON Web Token Claims |
| |
|
This document establishes an IETF URN Sub-namespace for use with JSON Web Token claims. |
| | PKCS #8 Private-Key Information Content Types |
| |
|
This document defines PKCS #8 Content Types for Private-Key Information. |
| | A YANG Module for Entitlement Inventory |
| |
|
This document proposes a YANG module for incorporating entitlements in a network inventory of entitlements. Entitlements define the rights for their holder to use specific feature(s) in a network element(s). The model is rooted by the concept of the capabilities offered by an element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ S/MIME. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | A reference architecture for direct presentation credential flows |
| |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. 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/leifj/wallet-refarch. |
| | Multicast Applicability for Distributed Consensus Systems |
| |
|
This document questions the applicability of a multicast semantic for the distributed consensus problem. For this, it details the consensus problem and the solutions taken in current systems. It outlines how point-to-multipoint communication arises as part of the consensus solution. Then, it details a peer-centric realization of a permissionless approach, identifying key issues. These issues include communication costs, performance delays, and lack of finality. Hence, it discusses a multicast strawman and its expected improvements. |
| | IGMP / MLD Extension for Signaling Eco-Mode |
| |
|
This document specifies an extension to IGMPv3 and MLDv2 messages to indicate eco mode in the delivery of multicast content based on the mechanism described in [RFC9279]. |
| | Including Privacy Pass Tokens in TLS Handshakes |
| |
|
This document defines a mechanism for TLS servers to request, and TLS clients to provide, Privacy Pass tokens as part of the Encrypted Client Hello in the TLS handshake. This creates a way to add support for anonymous attestation and rate-limiting to servers that are enforcing denial-of-service protections as part of processing TLS handshakes. |
| | Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS |
| |
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
| | Proposal for experimentation with stateless IPv6 multicast source routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing Headers (MRH) |
| |
|
This document proposes experimentation to evaluate benefits and feasibility of an IPv6 routing extension header based architecture, implementation and deployment of stateless IPv6 multicast specifically for IPv6 only networks using SRv6 for IP unicast. This experimentation intends to explore options to support easier proliferation of technologies developed by BIER-WG by providing an IPv6/SRv6 network optimized packet header and per-hop forwarding mechanisms than BIERin6. It also discusses how this work related to exploring advanced in-packet tree encoding mechanisms for both IPv6/ SRv6 networks as well as BIER networks as a related effort. |
| | Public Name Masquerade for TLS Encrypted Client Hello |
| |
|
An alternative method for authenticating Encrypted Client Hello (ECH) retry configurations is described. This method enables the use of multiple public names for the same server anonymity set. |
| | ACP free "Automation Network Infrastructure" for simple in-network automation (aNI) |
| |
|
This document describes how to to build the software infrastructure for distributed automation agents using a lightweight variation of the "Autonomic Networking Infrastructure" (ANI), by using the existing ANI domain keying material (certificates and trust anchors) as well as the protocols GRASP and BRSKI protocols, but eliminating the expensive to implement "Autonomic Control Plane" (ACP) and adding proxying "Autonomic Software Agents" (ASA) instead. The resulting infrastructure is called "automation Network Infrastructure" and can be implemented solely as application level software components on routers, switches or co-located managemenet devices, avoiding the need to change any router or switches forwarding or control-plane protocols. The aNI achieves mosts of the benefits of the ANI but foregoes the ability to easily make pre-existing, insecure control-plane protocols secure or provide all the same protection against operator or SDN controller misconfigurations that the ACP provides. |
| | Composite ML-DSA Authentication in the IKEv2 |
| |
|
This draft specifies composite ML-DSA authentication in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. Namely, the authenticaiton in the IKEv2 is completed by using a compiste signature of ML-DSA [FIPS203], the newly post-quantum digital singature standard, and one of the following traditional singature algorithms, SA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. These concrete composite algorithm specifications follow [OGPKF24]. Composite ML-DSA authenticatio is achieved by asking to add a new value in the "IKEv2 Authentication Method" registry [IANA-IKEv2], mantained by IANA. After that, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate the specific composite ML-DSA algoithms. [EDNOTE: Code points for composite ML-DSA authentication may need to be assigned in the "IKEv2 Authentication Method" registry, maintained by IANA] |
| | Secure Asset Transfer Protocol (SATP) Implementation Guide |
| |
|
This memo provides guidelines to developers of gateway systems, digital asset networks and client applications for the Secure Asset Transfer Protocol (SATP). Multiple gateways can represent the same digital asset network following the SATP standards, which necessitate basic implementation guidelines as outlined in this document. It also serves as an introduction to the SATP processing workflow for those new to the SATP standards. (Note. the initial draft (00) is submitted for a brief review regarding the document's direction by SATP WG members during IETF 12 in Bangkok, Mar 2025) |
| | MoQT Test |
| |
|
This document specifies the moq-test protocol, a testing protocol for Media over QUIC (MOQ) implementations. moq-test utilizes the Track Namespace as parameters to the publisher, enabling flexible and customizable testing scenarios. |
| | Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM |
| |
|
Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the “harvest now and decrypt later” threat posed by cryptanalytically-relevant quantum computers. For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in IKEv2 as an additional key exchange mechanism. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ] |
| | Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) |
| |
| | draft-sajassi-bess-rfc9251-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Ali Sajassi, Mankamana Mishra, Keyur Patel, Jorge Rabadan, Wen Lin |
| | Working Group: |
Individual Submissions (none) |
|
This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs). This document obsoletes RFC9251 (Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)). |
| | Use Case and Challanges for the Deployment of Object-Based Media across the Internet |
| |
|
This document outlines the challenges and use cases for the deployment and operation of Object-Based Media (OBM), also known as Flexible Media (FM), across the Internet. It discusses key considerations such as compute-aware traffic steering, metric usage, bandwidth optimization, and latency reduction techniques. The intention of this document is to highlight specific challanges or areas where IETF investigation and applicable solutions are needed for the optimal deployment of OBM-based media services. |
| | Deadline Aware Streams in MP-QUIC |
| |
|
This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (MP-QUIC). This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages MP-QUIC's path identifiers to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard MP-QUIC endpoints. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths. |
| | CBOR Encoding for HTTPS-based Transport for YANG Notifications |
| |
|
This document extends [I-D.draft-ietf-netconf-https-notif-15] by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes. |
| | Per-flow based EVPN DF Election |
| |
|
The Ethernet Virtual Private Network (EVPN) solution offers procedures for electing a Designated Forwarder (DF) for multihomed Ethernet Segments. In this context, the Provider Edge (PE) router is responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device or network. This applies in cases of an all-active multihomed Ethernet Segment (ES) as well as for BUM and unicast traffic in the case of single-active multi- homing. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the Ethernet Segment, but lacks in providing per flow based DF within the given EVPN Instances (EVIs). |
| | Staged IPv6 Transition of Domain Name Systems |
| |
|
This document specifies the three-stage IPv6 transition of Domain Name Systems (DNS) transport. The scope of this document is only the transport between authoritative servers and recursive servers, but does not include the transport of recursive servers for DNS clients. |
| | CCNx Content Versioning |
| |
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content sharing the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. |
| | SHA-3 for HPKE |
| |
|
This document defines Secure Hashing Algorithm-3 (SHA-3) options for Hybrid Public-Key Encryption (HPKE) as registered KDFs. |
| | Personal Data Portability Archive |
| |
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. |
| | OAuth 2.0 for Browser-Based Applications |
| |
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2 protocol as defined in [RFC6749] which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate. |
| | Transaction Tokens |
| |
|
Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to initiate transactions with protected user identity an authorization context throughout the call chain of the workloads required to complete the request. |
| | PCAP Capture File Format |
| |
| | draft-ietf-opsawg-pcap-05.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Guy Harris, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. |
| | PCAP Next Generation (pcapng) Capture File Format |
| |
| | draft-ietf-opsawg-pcapng-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Model-driven Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes 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 (e.g. 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 systems in order to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document proposes an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. |
| | PCEP Extension for Stateful Inter-Domain Tunnels |
| |
|
This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). The mechanism relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables them to be operated as end-to- end inter-domain paths, without the need for a signaling session between inter-domain border routers. It delivers a new tool in the PCE toolbox in order for operator to build Intent-Based Networking. For this purpose, this document defines a new Stitching Label, new Association Type, new PCEP communication Protocol (PCEP) Capability, new PCE Errors Type and new PCE Notifications Type. |
| | QUIC-LB: Generating Routable QUIC Connection IDs |
| |
|
QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. |
| | QUIC Address Discovery |
| |
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their public IP address and port for any QUIC path. |
| | (Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS |
| |
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. |
| | 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. |
| | Direct Anonymous Attestation for the Remote Attestation Procedures Architecture |
| |
| | draft-ietf-rats-daa-07.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | Concise Reference Integrity Manifest |
| |
| | draft-ietf-rats-corim-07.txt |
| | Date: |
03/03/2025 |
| | 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 or not 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. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. |
| | EAT Measured Component |
| |
|
The term "measured component" refers to an object within the attester's target environment whose state can be inspected and digested. A digest is typically computed through a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document defines a "measured component" format that can be used with the EAT Measurements claim. |
| | PKIX Key Attestation |
| |
| | draft-ietf-rats-pkix-key-attestation-00.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Mike Ounsworth, Jean-Pierre Fiset, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document specifies a vendor-agnostic format for attesting to the protection properties of a symmetric or asymmetric cryptographic key within a hardware cryptographic module to support applications such as providing evidence to a Certification Authority that a key is being protected in accordance with the requested certificate profile, or that HSMs can perform key import and maintain the private key protection properties in a robust way even when migrating keys across HSM vendors. This specification includes a format for requesting a key attestation containing certain attributes. This specification is called "PKIX Attestation" because it is designed to be easy to implement on top of a code base that already supports X.509 and PKCS#11 data models. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
| | draft-ietf-roll-enrollment-priority-12.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| | 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. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-04.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-11.txt |
| | Date: |
03/03/2025 |
| | 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 one or more Transparency Services, with the guarantee that any Relying Parties will be able to verify them. |
| | SCITT Reference APIs |
| |
| | draft-ietf-scitt-scrapi-04.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Henk Birkholz, 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. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. |
| | Human Readable Validate ROA Payload Notation |
| |
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. |
| | Human Readable ASPA Notation |
| |
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). |
| | RPKI Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| | RPKI Publication Server Best Current Practices |
| |
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. |
| | Path MTU (PMTU) for Segment Routing (SR) Policy |
| |
|
This document defines the Path MTU (PMTU) for Segment Routing (SR) Policy (called SR-PMTU). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU for SR Policy including the link MTU collection, the SR-PMTU computation, the SR-PMTU enforcement, and the handling behaviours on the headend. |
| | Out-of-Band STIR for Service Providers |
| |
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a Session Initiation Protocl (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. |
| | Secure Reporting of Update Status |
| |
| | draft-ietf-suit-report-11.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | SUIT Manifest Extensions for Multiple Trust Domains |
| |
|
This specification describes extensions to the SUIT Manifest format 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-10.txt |
| | Date: |
03/03/2025 |
| | 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. |
| | IETF Network Slice Application in 3GPP 5G End-to-End Network Slice |
| |
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. |
| | IETF Network Slice Controller and its Associated Data Models |
| |
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-21.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. |
| | TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key |
| |
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
The Transport Layer Security (TLS) 1.3 specification provides forward secrecy by utilizing an ephemeral key exchange during the initial handshake. Forward secrecy ensures that even if an attacker later obtains a party's long-term private key, past encrypted sessions cannot be decrypted. This protects against adversaries who record encrypted conversations in the hope of decrypting them later. TLS 1.3 also includes a Key Update mechanism, allowing cryptographic keys to be refreshed during an ongoing session. However, this update does not establish new forward-secret key material. While this is generally not an issue for short-lived sessions, it can pose a security risk for long-lived connections, such as those in industrial IoT or telecommunication networks, where an attacker could compromise application traffic secrets after the initial handshake. Earlier versions of TLS supported session renegotiation, a mechanism that allowed peers to establish new cryptographic parameters within an existing session. This included the ability to update the originally used long-term keys (certificates) with renewed credentials. However, due to security vulnerabilities, the renegotiation mechanism was modified via RFC 5746 and later removed entirely in TLS 1.3, leaving a gap in TLS's ability to refresh cryptographic material securely. This specification introduces an extended key update mechanism that supports forward secrecy, forcing attackers to continuously exfiltrate key material throughout the session to decrypt the entire conversation. |
| | TVR (Time-Variant Routing) Requirements |
| |
|
Time-Variant Routing (TVR) refers to calculating 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. |
| | Using ALTO for exposing Time-Variant Routing information |
| |
|
Network operations can require time-based, scheduled changes in nodes, links, adjacencies, etc. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can assist, as an off-path mechanism, on the exposure of such predicted changes to both internal and external applications then anticipating the occurrence of routing changes. This document describes how ALTO helps in that purpose. |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. 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. |
| | IPv6-Mostly Networks: Deployment and Operations Considerations |
| |
|
This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). |
| | 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. |
| | 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. |
| | WIMSE Workload to Workload Authentication |
| |
| | draft-ietf-wimse-s2s-protocol-03.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Brian Campbell, Joe Salowey, Arndt Schwenkschuster, Yaron Sheffer |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. |
| | Workload Identity Practices |
| |
|
The use of the OAuth 2.0 framework in container orchestration systems poses challenges, particularly in managing credentials such as client_id and client_secret, which can be complex and prone to errors. To address this, the industry has shifted towards a federation-based approach where credentials of the underlying workload platform are used as assertions towards an OAuth authorization server, leveraging the Assertion Framework for OAuth 2.0 Client Authentication [RFC7521], specifically [RFC7523]. This specification describes a meta flow in Section 3.1, gives security recommendations in Section 4 and outlines concrete patterns in Appendix A. It referes to existing industry practices that are mainly built on top of OAuth. It may not be in line with the (currently work in progress) WIMSE architecture [I-D.ietf-wimse-arch] and other protocols, such as [I-D.ietf-wimse-s2s-protocol]. |
| |
|
| |
| | Carrying Network Resource (NR) related Information in IPv6 Extension Header |
| |
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. 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 may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet are used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along a path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can also be generalized for other network resource semantics and functions. |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a query to the probed node and the probed node responds to the query. The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the query, as it arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it allows the user to see how the network modified the query as it traveled from the probing node to the probed node. |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. |
| | Supporting BIER in IPv6 Networks (BIERin6) |
| |
| | draft-ietf-bier-bierin6-11.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-11.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by one of the authenticated variants of HPKE. This document defines the use of the HPKE with COSE. |
| | Deterministic Networking (DetNet) Topology YANG Model |
| |
|
This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. |
| | Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members |
| |
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. This document updates [RFC9085] to allow the L2 Bundle Member Attributes TLV to be added to the BGP-LS Attribute associated with the Link NLRI of BGP peering link. This document updates [RFC9085] and [RFC9086] to allow the PeerAdj SID TLV to be included as a sub-TLV of the L2 Bundle Member Attributes TLV. |
| | 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. |
| | YANG Data Model for IS-IS SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. |
| | Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol |
| |
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. |
| | Network Overlay Impacts to Streaming Video |
| |
|
This document examines the operational impacts to streaming video applications caused by changes to network policies by network overlays. The network policy changes include IP address assignment, transport protocols, routing, DNS resolver which in turn affect a variety of important content delivery aspects such as latency, CDN cache selection, delivery path choices, traffic classification and content access controls. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated, and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | 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. It obsoletes RFC 6951. |
| | BGP-LS Advertisement of TE Policy Performance Metric |
| |
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| | INIT Forwarding for the Stream Control Transmission Protocol |
| |
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used in a variety of modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
| | draft-cx-mpls-mna-inband-pm-06.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Weiqiang Cheng, Xiao Min, Rakesh Gandhi, Greg Mirsky, Giuseppe Fioccola |
| | Working Group: |
Individual Submissions (none) |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | SRv6 Context Indicator SIDs for SR-Aware Services |
| |
|
A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. |
| | Inter-domain Source Address Validation based on AS relationships |
| |
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships. It mainly describes this method from five aspects: the research background in related fields, introduction to the AS relationship classification and acquisition methods, the SAV system's architecture, typical use cases, and considerations on deployability. |
| | 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. |
| | Data Generation and Optimization for Network Digital Twin Performance Modeling |
| |
|
Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network performance in various what-if scenarios. Recently, AI models, especially neural networks, have been applied for NDT performance modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model from the data perspective. |
| | 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. |
| | Kademlia-directed ID-based Routing Architecture (KIRA) |
| |
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Payload Protocol Identifier based Fragmentation and Reassembly for the Stream Control Transmission Protocol |
| |
|
This document describes a method for the Stream Control Transmission Protocol (SCTP) allowing the upper layer to perform fragmentation, reassembly, and interleaving of large ordered user messages by using the payload protocol identifier (PPID). According to the base specification supporting fragmentation of large user messages is optional. And even if an SCTP implementation supports fragmentation, interleaving of user messages is not supported by the base specification. |
| | Outer Header Translator |
| |
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. |
| | CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing Chains of CBOR Web Tokens (CWTs) |
| |
|
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. This specification extends this functionality to CBOR Web Tokens (CWTs). |
| | Intra-domain SAVNET Support via IGP |
| |
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. |
| | Mobile User Plane Architecture for Distributed Mobility Management |
| |
| | draft-mhkk-dmm-mup-architecture-02.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Satoru Matsushima, Katsuhiro Horiba, Yuya Kawakami, Tetsuya Murakami, Keyur Patel, Jakub Horn |
| | 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 (SRv6 MUP) due to the DMM requirement, and is suitable for mobile services which require a large IP address space. |
| | MPLS Network Action for Deterministic Latency |
| |
|
This document specifies formats and principles for the MPLS Network Action for Deterministic Latency to provide guaranteed latency services. They are used to make scheduling decisions for time- sensitive services running on Deterministic Network (DetNet) nodes that operate within a single or multiple domains. |
| | Segment Routing Policy Extension for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document describes how the SR Policy extension for associated NRP and the operational mechanisms function together. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) framework. |
| | Lightweight GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the UDP-based Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP), which is designed to be a lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. LW-GRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Given the established ecosystem of CoAP and aiming to promote LW- GRASP adoption in IoT, this document also focuses on the LW-GRASP transition from UDP to a CoAP-based framework, i.e., LW-GRASP over CoAP. Furthermore, this document also discusses the potential way to adapt the LW-GRASP to work on the network without IP connectivity. |
| | Source Address Validation Enhanced by Network Controller |
| |
|
Many newly proposed Source Address Validation (SAV) mechanisms such as IGP-based and BGP-based SAVNET solutions take a distributed manner to generate SAV rules, but they are faced with accuracy and managability challenges in incremental/partial deployment scenarios. This document proposes a network controller-based solution for enhancing SAVNET capability in intra-domain and inter-domain networks, which supports accurate verification, automated configuration, threat analysis, traceability and visualization. |
| | Collision Free Keytags for DNSSEC |
| |
|
DNSSEC employs a Key Tag field in the RRSIG and DS resource records in order to efficiently identify the key that produced a DNSSEC signature and the key that should be used as a secure entry point into a delegated zone. The Key Tag was not intended to be a unique identifier. Key tag collisions can occur in practice for keys in the same zone, though they are relatively rare in normal operation. Colliding key tags impose additional work on a validating resolver because it then has to check signatures for each of the candidate set of keys identified by the Key Tag. Furthermore, they open up resolvers to computational denial of service attacks by adversaries deploying specially crafted zones with many intentionally colliding key tags. This document specifies updates to the DNSSEC protocol and the process of key generation to avoid colliding key tags. |
| | Secure Key Integration Protocol (SKIP) |
| |
| | draft-cisco-skip-01.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Rajiv Singh, Craig Hill, Scott Kawaguchi, Joey Lupo |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. |
| | SR based Loop-free implementation |
| |
|
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | Automation Scenarios and Requirements for Autonomous Networking (AN) Level 4 |
| |
|
This document describes a scenario of OTN-WDM service automation and collaboration in transport networks and defines related functional requirements for domain controller. |
| | Serialization of MoQ Objects to Files |
| |
|
This specification provides a way to save the metadata about each MoQ Object in one or more files as well as pointers to other files that contain the contents of the object. Separating of the metadata and payload data allows the payload data to remain in files that are used for other purposes such as serving HLS/DASH video. This format makes it easier to test and develop caching relays and create test data they can serve to clients. |
| | Simple Time Over MoQ Protocol (STOMP) |
| |
|
This document describes Simple Time Over MoQ Protocol (STOMP), a protocol for sending the local time and, optionally, location information via Media Over QUIC Transport (MOQT) protocol [I-D.ietf-moq-transport]. Such information enables observing endpoints to measure latencies and monitor health of MOQT delivery network from different geographical locations. |
| | Controlling IP Fragmentation on Common Platforms |
| |
|
When performing Path MTU Discovery (PMTUD) over UDP, applications must prevent fragmentation of UDP datagrams both by the sender's kernel and during network transit. This document provides guidance for implementers on configuring socket options to prevent fragmentation of IPv4 and IPv6 packets across commonly used platforms. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | A profile for FC path attribute |
| |
|
This document specifies a mechanism for embedding a new path attribute, known as the FC path attribute, into BGP UPDATE messages. The FC (Forwarding Commitment) is a cryptographically signed object to certify an AS's routing intent on its directly connected hops. By incorporating the FC path attribute into BGP UPDATE messages, this mechanism provides enhanced route authenticity and lays the groundwork for improved data-plane forwarding verification. This mechanism is backward compatible, which means a router that supports the attribute can interoperate with a router that doesn't, allowing partial deployment across the Internet. |
| | Messaging Layer Security credentials using Selective Disclosure CBOR Web Tokens |
| |
|
The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. |
| | Yang Templates |
| |
|
Yang Templates is a way to more easily manage a network device's configuration when parts of that configuration are repetitive. This document provides a high-level description of Yang Templates, and is expected to evolve into a full solution in later versions. |
| | A Common YANG Data Model for Energy Efficiency Network Management |
| |
|
This document defines a common YANG module that is meant to be reused by various energy efficiency-related modules such as energy saving Network models, energy saving network inventory model and energy saving device models. |
| | A Network Inventory Data Model for Energy Efficiency Management |
| |
|
As a complement to the YANG Network Topology Data Model for Energy Efficiency Management, which is used for monitoring the dynamic energy consumption of network devices, this document defines YANG Network Inventory Data Model for Energy Efficiency Management that can be used for maintaining capability related energy efficiency attributes. The model provides both network view and device view of energy efficiency related inventory information. |
| | A Network Topology Data Model for Energy Efficiency Management |
| |
|
This document defines a YANG Network Topology Data Model that can be used for Energy Efficiency Management within a network. The model provides both network-centric view of energy consumption of network devices and device view of energy consumption of individual components within network devices. |
| | Credit-based Flow Control for Cross-AIDC WAN transmission Based on RSVP |
| |
|
This draft defines the Credit-based flow control mechanism for WAN based on the RSVP protocol. With the increasing demand for AI computing power, the computing power of a single AIDC can no longer meet the needs of large model training. This has given rise to cross-AIDC distributed model training, driving the demand for transmitting RoCEv2 packets over WAN networks. AI training is extremely sensitive to network packet loss, and even a small amount of packet loss may lead to a significant decline in training efficiency. In addition, the elephant flow and extreme concurrent traffic also place higher demands on network performance. Credit- based flow control is a Backpressure-based traffic management technology, which has high reliability and stability in practical applications. It can provide high-throughput and zero-packet-loss transmission guarantees for RoCEv2 traffic, effectively ensuring the efficiency of cross-data center AI training. This draft focuses on the scenario where RoCEv2 packets are transmitted through SRv6 tunnels in the WAN and further expands the capabilities of the RSVP protocol in WAN. This draft introduces the Credit-based flow control mechanism into the RSVP protocol to achieve precise traffic control and provides processing analysis. |
| | Zero Trust Network Access DM for Network Cloud Interface |
| |
|
This document defines a YANG data model for implementing Zero Trust Network Access (ZTNA) principles at the network-cloud interface. It addresses security gaps in traditional network architectures by enforcing identity-based access control, least privilege enforcement, secure exposure of resources, and continuous monitoring. The model enables real-time policy enforcement between Cloud-Aware Service Orchestrators and Network Controllers, ensuring that only authorized entities have access to specific network and cloud telemetry. |
| | Fast congestion notification for distributed RoCEv2 network based on SRv6 |
| |
| | draft-hu-rtgwg-rocev2-fcn-00.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Zehua Hu, Yongqing Zhu, Xuesong Geng, Jiayuan Hu, Tanxin Pi |
| | Working Group: |
Individual Submissions (none) |
|
AI services (e.g. distributed model training, separated storage and model training) drive the need to transmit RMDA packets through SRv6 tunnels in WAN. RoCEv2 is the most popular open standard for achieving RDMA and network offloads over ethernet, with its congestion control based on the combination of PFC and ECN. The document defines the fast congestion notification for distributed RoCEv2 network based on SRv6 tunnels, and further extends PFC and ECN to achieve precise flow control and end-to-end congestion control. |
| | SRv6 Path Verification |
| |
|
This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specificed by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. And this approach also significantly reduces the processing overhead associated with hop- by-hop path verification. |
| | ML-KEM and Hybrid Cipher Suites for Messaging Layer Security |
| |
| | draft-mahy-mls-pq-00.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Rohan Mahy, Richard Barnes |
| | Working Group: |
Individual Submissions (none) |
|
This document reigsters new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. |
| | PCE SR Policy Extensions for Path Scheduling |
| |
|
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios. This document proposes extensions to PCE SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes. |
| | Routing in Satellite Networks: Challenges & Considerations |
| |
|
The SDO 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on the satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves the significant work to be explored in the IETF domain. This draft stems from the 3GPP satellite use cases that have been studied for many years up to now, across a couple of releases, and lands on summarizing the challenges & considerations of the satellite-based routing. Based on some unique & advantageous characteristics associated with satellite networks, the draft raises briefly the general routing considerations for the integrated Non- Terrestrial & Terrestial Networks. |
| | PCEP Extension for Layer 2 (L2) Flow Specification |
| |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. |
| | Supporting Asymmetric Links in Low Power Networks: AODV-RPL |
| |
| | draft-ietf-roll-aodv-rpl-20.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Charles Perkins, S.V.R Anand, Satish Anamalamudi, Bing Liu |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. |
| | SPICE SD-CWT |
| |
| | draft-ietf-spice-sd-cwt-03.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This document describes a data minimization technique for use with CBOR Web Token (CWT). The approach is based on Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE). |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes the mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. A list of resource-aware SIDs can be used to allow an SR Policy to use a specific set of network resources, and a group of resource-aware SIDs can be used to represent a virtual network with a specific set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-05.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. |
| | Scalability Considerations for Network Resource Partition |
| |
| | draft-ietf-teas-nrp-scalability-07.txt |
| | Date: |
02/03/2025 |
| | 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 9543 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. |
| | YANG Data Models for Network Resource Partitions (NRPs) |
| |
| | draft-ietf-teas-nrp-yang-03.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. |
| | Workload Identity in a Multi System Environment (WIMSE) Architecture |
| |
| | draft-ietf-wimse-arch-04.txt |
| | Date: |
02/03/2025 |
| | Authors: |
Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. |