| |
| RFC 9700 | Best Current Practice for OAuth 2.0 Security |
| |
|
|
This document describes best current security practice for OAuth 2.0.It updates and extends the threat model and security advice given inRFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. |
|
| |
| RFC 9701 | JSON Web Token (JWT) Response for OAuth Token Introspection |
| |
| Authors: | T. Lodderstedt, Ed., V. Dzhuvinov. |
| Date: | January 2025 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9701 |
|
This specification proposes an additional response secured by JSONWeb Token (JWT) for OAuth 2.0 Token Introspection. |
|
| |
| RFC 9702 | YANG Data Model for Maximum Segment Identifier (SID) Depth (MSD) Types and MPLS MSD |
| |
| Authors: | Y. Qu, A. Lindem, S. Litkowski, J. Tantsura. |
| Date: | January 2025 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9702 |
|
This document defines two YANG modules. The first module is the initial version of the IANA-maintained YANG module for MaximumSegment Identifier (SID) Depth (MSD) Types, which includes identities for both the MPLS data plane and Segment Routing over IPv6 (SRv6) data plane. The second module augments the IETF MPLS YANG data model to provide support for MPLS MSDs as defined in RFCs 8476 and 8491. |
|
| |
| RFC 9703 | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS Data Plane |
| |
| Authors: | S. Hegde, M. Srivastava, K. Arora, S. Ninan, X. Xu. |
| Date: | December 2024 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9703 |
|
Egress Peer Engineering (EPE) is an application of Segment Routing(SR) that solves the problem of egress peer selection. The SR-basedBGP-EPE solution allows a centralized controller, e.g., a Software-Defined Network (SDN) controller, to program any egress peer. TheEPE solution requires the node or the SDN controller to program 1) the PeerNode Segment Identifier (SID) describing a session between two nodes, 2) the PeerAdj SID describing the link or links that are used by the sessions between peer nodes, and 3) the PeerSet SID describing any connected interface to any peer in the related group.This document provides new sub-TLVs for EPE-SIDs that are used in theTarget FEC Stack TLV (Type 1) in MPLS Ping and Traceroute procedures. |
|
| |
| RFC 9704 | Establishing Local DNS Authority in Validated Split-Horizon Environments |
| |
| Authors: | T. Reddy.K, D. Wing, K. Smith, B. Schwartz. |
| Date: | January 2025 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9704 |
|
When split-horizon DNS is deployed by a network, certain domain names can be resolved authoritatively by a network-provided DNS resolver.DNS clients that are not configured to use this resolver by default can use it for these specific domains only. This specification defines a mechanism for domain owners to inform DNS clients about local resolvers that are authorized to answer authoritatively for certain subdomains. |
|
| |
| RFC 9706 | TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences |
| |
| Authors: | L. Giuliano, C. Lenart, R. Adam. |
| Date: | January 2025 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9706 |
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and Augmented Reality (AR), live streaming can place a unique type of stress upon network resources.TreeDN is a tree-based Content Delivery Network (CDN) architecture designed to address the distinctive scaling challenges of live streaming to mass audiences. TreeDN enables operators to offerReplication-as-a-Service (RaaS) at a fraction of the cost of traditional, unicast-based CDNs -- in some cases, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously were not possible or economically viable using traditionalCDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology that makes content distribution more accessible to more people by dramatically reducing the costs of replication. |
|
| |
| RFC 9708 | Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC8708. |
|
| |
| RFC 9709 | Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Using HKDF with SHA-256 |
| |
|
|
This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the CryptographicMessage Syntax (CMS) using the HMAC-based Extract-and-Expand KeyDerivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against an attacker that manipulates the content- encryption algorithm identifier or the content-authenticated- encryption algorithm identifier. |
|
| |
| RFC 9712 | IETF Meeting Venue Requirements Review |
| |
|
|
Following a review of the IETF meeting venue requirements, this document updates RFC 8718 ("IETF Plenary Meeting Venue SelectionProcess"), clarifies how the IETF Administration Support Activity(IASA) should interpret some elements of RFC 8718, and specifies a replacement exploratory meeting process, thereby updating RFC 8719("High-Level Guidance for the Meeting Policy of the IETF"). |
|
| |
| RFC 9713 | Bundle Protocol Version 7 Administrative Record Types Registry |
| |
|
|
This document updates RFC 9171 to clarify that Bundle ProtocolVersion 7 agents are expected to use the IANA "Bundle AdministrativeRecord Types" registry to identify and document administrative record types. This document also designates code points for Private andExperimental Use. |
|
| |
| RFC 9715 | IP Fragmentation Avoidance in DNS over UDP |
| |
|
|
The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by aDNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols.It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade fromUDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. |
|
| |
| RFC 9717 | A Routing Architecture for Satellite Networks |
| |
|
|
Satellite networks present some interesting challenges for packet networking. The entire topology is continually in motion, with links far less reliable than what is common in terrestrial networks. Some changes to link connectivity can be anticipated due to orbital dynamics.
This document proposes a scalable routing architecture for satellite networks based on existing routing protocols and mechanisms that is enhanced with scheduled link connectivity change information. This document proposes no protocol changes.
This document presents the author's view and is neither the product of the IETF nor a consensus view of the community. |
|
| |
| RFC 9718 | DNSSEC Trust Anchor Publication for the Root Zone |
| |
|
|
The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.
This document obsoletes RFC 7958. |
|
