| |
| RFC 9100 | Sensor Measurement Lists (SenML) Features and Versions |
| |
|
|
This short document updates RFC 8428, "Sensor Measurement Lists(SenML)", by specifying the use of independently selectable "SenMLFeatures" and mapping them to SenML version numbers. |
|
| |
| RFC 9101 | The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) |
| |
| Authors: | N. Sakimura, J. Bradley, M. Jones. |
| Date: | August 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9101 |
|
The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.
This document introduces the ability to send request parameters in aJSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption(JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained.The request can be sent by value or by reference. |
|
| |
| RFC 9102 | TLS DNSSEC Chain Extension |
| |
| Authors: | V. Dukhovni, S. Huque, W. Toorop, P. Wouters, M. Shore. |
| Date: | August 2021 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9102 |
|
This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated byDNSSEC and that are needed to perform DNS-Based Authentication ofNamed Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial- of-existence proof that can be validated.
This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations. |
|
| |
| RFC 9103 | DNS Zone Transfer over TLS |
| |
|
|
DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature(TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC7766 with respect to the recommended number of connections between a client and server for each transport. |
|
| |
| RFC 9104 | Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) |
| |
| Authors: | J. Tantsura, Z. Wang, Q. Wu, K. Talaulikar. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9104 |
|
Administrative groups are link attributes used for traffic engineering. This document defines an extension to the BorderGateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs). |
|
| |
| RFC 9105 | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
| Authors: | B. Wu, Ed., G. Zheng, M. Wang, Ed.. |
| Date: | August 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9105 |
|
This document defines a Terminal Access Controller Access-ControlSystem Plus (TACACS+) client YANG module that augments the SystemManagement data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC8907), and TACACS+ MUST be used within a secure deployment.
The YANG module in this document conforms to the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 9106 | Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications |
| |
| Authors: | A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson. |
| Date: | September 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9106 |
|
This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9107 | BGP Optimal Route Reflection (BGP ORR) |
| |
| Authors: | R. Raszuk, Ed., B. Decraene, Ed., C. Cassar, E. Åman, K. Wang. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9107 |
|
This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").
The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP. |
|
| |
| RFC 9108 | YANG Types for DNS Classes and Resource Record Types |
| |
| Authors: | L. Lhotka, P. Špaček. |
| Date: | September 2021 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9108 |
|
This document introduces the YANG module "iana-dns-class-rr-type", which contains derived types reflecting two IANA registries: DNSCLASSes and Resource Record (RR) TYPEs. These YANG types are intended as the minimum basis for future data modeling work. |
|
| |
| RFC 9109 | Network Time Protocol Version 4: Port Randomization |
| |
|
|
The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port.However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. |
|
| |
| RFC 9110 | HTTP Semantics |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2022 |
| Formats: | txt json xml html pdf |
| Obsoletes: | RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694 |
| Updates: | RFC 3864 |
| Also: | STD 0097 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 9110 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232,7233, 7235, 7538, 7615, 7694, and portions of 7230. |
|
| |
| RFC 9111 | HTTP Caching |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
This document obsoletes RFC 7234. |
|
| |
| RFC 9112 | HTTP/1.1 |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.
This document obsoletes portions of RFC 7230. |
|
| |
| RFC 9113 | HTTP/2 |
| |
|
|
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFCs 7540 and 8740. |
|
| |
| RFC 9114 | HTTP/3 |
| |
|
|
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. |
|
| |
| RFC 9115 | An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates |
| |
| Authors: | Y. Sheffer, D. López, A. Pastor Perales, T. Fossati. |
| Date: | September 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9115 |
|
This document defines a profile of the Automatic CertificateManagement Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain anX.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of aContent Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time.Importantly, this mechanism does not require any modification to the deployed TLS clients and servers. |
|
| |
| RFC 9116 | A File Format to Aid in Security Vulnerability Disclosure |
| |
|
|
When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. |
|
| |
| RFC 9117 | Revised Validation Procedure for BGP Flow Specifications |
| |
| Authors: | J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. Mohapatra. |
| Date: | August 2021 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9117 |
|
This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border GatewayProtocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originateBGP Flow Specifications. Sometimes it is desirable to originate theBGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller.However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an ExternalBorder Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.
This document updates the validation procedure in RFC 8955. |
|
| |
| RFC 9118 | Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates |
| |
|
|
RFC 8226 specifies the use of certificates for Secure TelephoneIdentity Credentials; these certificates are often called "SecureTelephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. |
|
| |
| RFC 9119 | Multicast Considerations over IEEE 802 Wireless Media |
| |
| Authors: | C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zúñiga. |
| Date: | October 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9119 |
|
Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices. |
|
| |
| RFC 9120 | Nameservers for the Address and Routing Parameter Area ("arpa") Domain |
| |
|
|
This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone. |
|
| |
| RFC 9121 | Deprecating Infrastructure "int" Domains |
| |
|
|
This document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and it identifies them for removal from the "int" top-level domain. Any implementations that involve these domains are now deprecated. This document also changes the status of RFC 1528 and RFC 1706 toHistoric. |
|
| |
| RFC 9122 | IANA Registry for Sieve Actions |
| |
| Authors: | A. Melnikov, K. Murchison. |
| Date: | June 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9122 |
|
The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions. |
|
| |
| RFC 9124 | A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices |
| |
| Authors: | B. Moran, H. Tschofenig, H. Birkholz. |
| Date: | January 2022 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9124 |
|
Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.
One component of such a firmware update is a concise and machine- processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. |
|
| |
| RFC 9125 | Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing |
| |
| Authors: | A. Farrel, J. Drake, E. Rosen, K. Patel, L. Jalil. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9125 |
|
Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.
This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes. |
|
| |
| RFC 9126 | OAuth 2.0 Pushed Authorization Requests |
| |
| Authors: | T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan. |
| Date: | September 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9126 |
|
This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. |
|
| |
| RFC 9127 | YANG Data Model for Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky. |
| Date: | October 2021 |
| Formats: | txt html pdf xml json |
| Updated by: | RFC 9314 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9127 |
|
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342). |
|
| |
| RFC 9128 | YANG Data Model for Protocol Independent Multicast (PIM) |
| |
| Authors: | X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu. |
| Date: | October 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9128 |
|
This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM).The model covers the PIM protocol configuration, operational state, and event notifications data. |
|
| |
| RFC 9129 | YANG Data Model for the OSPF Protocol |
| |
| Authors: | D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem. |
| Date: | October 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9129 |
|
This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture(NMDA) as described in RFC 8342. |
|
| |
| RFC 9130 | YANG Data Model for the IS-IS Protocol |
| |
| Authors: | S. Litkowski, Ed., D. Yeung, A. Lindem, J. Zhang, L. Lhotka. |
| Date: | October 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9130 |
|
This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. |
|
| |
| RFC 9131 | Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers |
| |
|
|
Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a newIPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address. |
|
| |
| RFC 9132 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification |
| |
| Authors: | M. Boucadair, Ed., J. Shallow, T. Reddy.K. |
| Date: | September 2021 |
| Formats: | txt html pdf json xml |
| Obsoletes: | RFC 8782 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9132 |
|
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.
This document obsoletes RFC 8782. |
|
| |
| RFC 9133 | Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel |
| |
| Authors: | K. Nishizuka, M. Boucadair, T. Reddy.K, T. Nagata. |
| Date: | September 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9133 |
|
This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so thatDOTS clients can control their filtering rules when an attack mitigation is active.
Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol. |
|
| |
| RFC 9134 | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
| Authors: | T. Bruylants, A. Descampe, C. Damman, T. Richter. |
| Date: | October 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9134 |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame. |
|
| |
| RFC 9135 | Integrated Routing and Bridging in Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan. |
| Date: | October 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9135 |
|
Ethernet VPN (EVPN) provides an extensible and flexible multihomingVPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual.However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities ofEVPN. This document describes an Integrated Routing and Bridging(IRB) solution based on EVPN to address such requirements. |
|
| |
| RFC 9136 | IP Prefix Advertisement in Ethernet VPN (EVPN) |
| |
| Authors: | J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi. |
| Date: | October 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9136 |
|
The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in anMPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used. |
|
| |
| RFC 9137 | Considerations for Cancellation of IETF Meetings |
| |
|
|
The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet. However, various events can make a planned in-person meeting infeasible. This document provides criteria to aid the IETF Administration LLC (IETF LLC), the InternetEngineering Steering Group (IESG), and the Chair of the InternetResearch Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting. |
|
| |
| RFC 9138 | Design Considerations for Name Resolution Service in Information-Centric Networking (ICN) |
| |
| Authors: | J. Hong, T. You, L. Dong, C. Westphal, B. Ohlman. |
| Date: | December 2021 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9138 |
|
This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking(ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 9139 | Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) |
| |
| Authors: | C. Gündoğan, T. Schmidt, M. Wählisch, C. Scherb, C. Marxer, C. Tschudin. |
| Date: | November 2021 |
| Formats: | txt xml pdf json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9139 |
|
This document defines a convergence layer for Content-CentricNetworking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN.Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links.Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9140 | Nimble Out-of-Band Authentication for EAP (EAP-NOOB) |
| |
| Authors: | T. Aura, M. Sethi, A. Peltonen. |
| Date: | December 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9140 |
|
The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange.The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length. |
|
| |
| RFC 9141 | Updating References to the IETF FTP Service |
| |
| Authors: | R. Danyliw. |
| Date: | November 2021 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 2077, RFC 2418, RFC 2648, RFC 2954, RFC 2955, RFC 3020, RFC 3083, RFC 3201, RFC 3202, RFC 3295, RFC 3684, RFC 3962, RFC 3970, RFC 4036, RFC 4131, RFC 4251, RFC 4323, RFC 4546, RFC 4547, RFC 4639, RFC 4682, RFC 5098, RFC 5428, RFC 6756, RFC 7241 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9141 |
|
The IETF FTP service running at ftp.ietf.org, ops.ietf.org, and ietf.org will be retired. A number of published RFCs in the IETF andIAB streams include URIs that reference this FTP service. To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs. |
|
| |
| RFC 9142 | Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) |
| |
|
|
This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462. |
|
| |
| RFC 9143 | Negotiating Media Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941.
This specification obsoletes RFC 8843. |
|
| |
| RFC 9144 | Comparison of Network Management Datastore Architecture (NMDA) Datastores |
| |
| Authors: | A. Clemm, Y. Qu, J. Tantsura, A. Bierman. |
| Date: | December 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9144 |
|
This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network ManagementDatastore Architecture (NMDA). |
|
| |
| RFC 9145 | Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers |
| |
| Authors: | M. Boucadair, T. Reddy.K, D. Wing. |
| Date: | December 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9145 |
|
This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used forService Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH. |
|
| |
| RFC 9146 | Connection Identifier for DTLS 1.2 |
| |
| Authors: | E. Rescorla, Ed., H. Tschofenig, Ed., T. Fossati, A. Kraus. |
| Date: | March 2022 |
| Formats: | txt json html pdf xml |
| Updates: | RFC 6347 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9146 |
|
This document specifies the Connection ID (CID) construct for theDatagram Transport Layer Security (DTLS) protocol version 1.2.
A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.
The new ciphertext record format with the CID also provides content type encryption and record layer padding.
This document updates RFC 6347. |
|
| |
| RFC 9147 | The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 |
| |
|
|
This document specifies version 1.3 of the Datagram Transport LayerSecurity (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
This document obsoletes RFC 6347. |
|
| |
| RFC 9148 | EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol |
| |
| Authors: | P. van der Stok, P. Kampanakis, M. Richardson, S. Raza. |
| Date: | April 2022 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9148 |
|
Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. |
|
| |
| RFC 9149 | TLS Ticket Requests |
| |
| Authors: | T. Pauly, D. Schinazi, C.A. Wood. |
| Date: | April 2022 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9149 |
|
TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste while simultaneously priming clients for future connection attempts. |
|
| |
| RFC 9150 | TLS 1.3 Authentication and Integrity-Only Cipher Suites |
| |
|
|
This document defines the use of cipher suites for TLS 1.3 based onHashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced- security mechanism that provides authentication and message integrity without supporting confidentiality. |
|
| |
| RFC 9151 | Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 |
| |
|
|
This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS orDTLS. 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. |
|
| |
| RFC 9152 | Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients |
| |
|
|
This document specifies protocol interfaces profiled by the UnitedStates National Security Agency (NSA) for National Security System(NSS) servers that provide public key certificates, CertificateRevocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure ObjectDelivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport(EST) and its extensions as well as Certificate Management over CMS(CMC).
This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9153 | Drone Remote Identification Protocol (DRIP) Requirements and Terminology |
| |
| Authors: | S. Card, Ed., A. Wiethuechter, R. Moskowitz, A. Gurtov. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9153 |
|
This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) WorkingGroup. These solutions will support Unmanned Aircraft System RemoteIdentification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existingInternet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. |
|
| |
| RFC 9154 | Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer |
| |
| Authors: | J. Gould, R. Wilhelm. |
| Date: | December 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9154 |
|
The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information. This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers. |
|
| |
| RFC 9155 | Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 |
| |
|
|
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS1.2 digital signatures. However, this document does not deprecateSHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246. |
|
| |
| RFC 9156 | DNS Query Name Minimisation to Improve Privacy |
| |
|
|
This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. |
|
| |
| RFC 9157 | Revised IANA Considerations for DNSSEC |
| |
|
|
This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updatesRFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for HashedAuthenticated Denial of Existence). It also updates RFCs 5155 and6014, which have requirements for DNSSEC algorithms, and updates RFC8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. |
|
| |
| RFC 9158 | Update to the Object Identifier Registry for the PKIX Working Group |
| |
|
|
RFC 7299 describes the object identifiers that were assigned by thePublic Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight. |
|
| |
| RFC 9159 | IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) |
| |
| Authors: | C. Gomez, S.M. Darroudi, T. Savolainen, M. Spoerk. |
| Date: | December 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9159 |
|
RFC 7668 describes the adaptation of IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) techniques to enable IPv6 overBluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol SupportProfile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links. |
|
| |
| RFC 9160 | Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) |
| |
|
|
This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on whichMPLS control plane protocol is used within a Segment Routing domain.In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element(PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. |
|
| |
| RFC 9161 | Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, G. Hankins, T. King. |
| Date: | January 2022 |
| Formats: | txt pdf xml html json |
| Updates: | RFC 7432 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9161 |
|
This document describes the Ethernet Virtual Private Network (EVPN)Proxy ARP/ND function augmented by the capability of the ARP/NDExtended Community. From that perspective, this document updates theEVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of InternetExchange Points, Data Centers, and other networks deal with IPv4 andIPv6 address resolution issues associated with large BroadcastDomains by reducing and even suppressing the flooding produced by address resolution in the EVPN network. |
|
| |
| RFC 9162 | Certificate Transparency Version 2.0 |
| |
|
|
This document describes version 2.0 of the Certificate Transparency(CT) protocol for publicly logging the existence of Transport LayerSecurity (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.
This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. |
|
| |
| RFC 9163 | Expect-CT Extension for HTTP |
| |
|
|
This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. |
|
| |
| RFC 9164 | Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes |
| |
| Authors: | M. Richardson, C. Bormann. |
| Date: | December 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9164 |
|
This specification defines two Concise Binary Object Representation(CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. |
|
| |
| RFC 9165 | Additional Control Operators for the Concise Data Definition Language (CDDL) |
| |
|
|
The Concise Data Definition Language (CDDL), standardized in RFC8610, provides "control operators" as its main language extension point.
The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat, and.det for the construction of constants; .abnf/.abnfb for includingABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for indicating the use of a non-basic feature in an instance. |
|
| |
| RFC 9166 | A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping |
| |
| Authors: | H. Zhao, X. Liu, Y. Liu, A. Peter, M. Sivakumar. |
| Date: | February 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9166 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9167 | Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | T. Sattler, R. Carney, J. Kolker. |
| Date: | December 2021 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9167 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to queryEPP servers regarding maintenance events. |
|
| |
| RFC 9168 | Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification |
| |
| Authors: | D. Dhody, A. Farrel, Z. Li. |
| Date: | January 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9168 |
|
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 "FlowSpecifications". 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.
This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.
The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. |
|
| |
| RFC 9169 | New ASN.1 Modules for the Evidence Record Syntax (ERS) |
| |
|
|
The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate ValidationProtocol (SCVP) are expressed using ASN.1. This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax. |
|
| |
| RFC 9170 | Long-Term Viability of Protocol Extension Mechanisms |
| |
|
|
The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. |
|
| |
| RFC 9171 | Bundle Protocol Version 7 |
| |
| Authors: | S. Burleigh, K. Fall, E. Birrane, III. |
| Date: | January 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9171 |
|
This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the InternetResearch Task Force and documented in RFC 5050. |
|
| |
| RFC 9172 | Bundle Protocol Security (BPSec) |
| |
| Authors: | E. Birrane, III, K. McKeever. |
| Date: | January 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9172 |
|
This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). |
|
| |
| RFC 9173 | Default Security Contexts for Bundle Protocol Security (BPSec) |
| |
| Authors: | E. Birrane, III, A. White, S. Heiner. |
| Date: | January 2022 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9173 |
|
This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network. |
|
| |
| RFC 9174 | Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 |
| |
| Authors: | B. Sipos, M. Demmer, J. Ott, S. Perreault. |
| Date: | January 2022 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9174 |
|
This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by theConcise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles.This TCPCL version also includes security and extensibility mechanisms. |
|
| |
| RFC 9175 | Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing |
| |
|
|
This document specifies enhancements to the Constrained ApplicationProtocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non- secure reuse of Tokens to ensure response-to-request binding whenCoAP is used with a security protocol, and amplification mitigation(where the use of the Echo option is now recommended). |
|
| |
| RFC 9176 | Constrained RESTful Environments (CoRE) Resource Directory |
| |
| Authors: | C. Amsüss, Ed., Z. Shelby, M. Koster, C. Bormann, P. van der Stok. |
| Date: | April 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9176 |
|
In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources.Furthermore, new target attributes useful in conjunction with an RD are defined. |
|
| |
| RFC 9177 | Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission |
| |
| Authors: | M. Boucadair, J. Shallow. |
| Date: | March 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9177 |
|
This document specifies alternative Constrained Application Protocol(CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
These options are similar to, but distinct from, the CoAP Block1 andBlock2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, theQ-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. |
|
| |
| RFC 9178 | Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks |
| |
| Authors: | J. Arkko, A. Eriksson, A. Keränen. |
| Date: | May 2022 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9178 |
|
This memo discusses the use of the Constrained Application Protocol(CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. |
|
| |
| RFC 9179 | A YANG Grouping for Geographic Locations |
| |
|
|
This document defines a generic geographical location YANG grouping.The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object. |
|
| |
| RFC 9180 | Hybrid Public Key Encryption |
| |
| Authors: | R. Barnes, K. Bhargavan, B. Lipp, C. Wood. |
| Date: | February 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9180 |
|
This document describes a scheme for hybrid public key encryption(HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such asElliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9181 | A Common YANG Data Model for Layer 2 and Layer 3 VPNs |
| |
| Authors: | S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., Q. Wu. |
| Date: | February 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9181 |
|
This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models. |
|
| |
| RFC 9182 | A YANG Network Data Model for Layer 3 VPNs |
| |
| Authors: | S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., L. Munoz, A. Aguado. |
| Date: | February 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9182 |
|
As a complement to the Layer 3 Virtual Private Network Service Model(L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network(L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.
The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. |
|
| |
| RFC 9183 | Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | M. Zhang, D. Eastlake 3rd, R. Perlman, M. Cullen, H. Zhai. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9183 |
|
A major issue in multilevel TRILL is how to manage RBridge nicknames.In this document, area border RBridges use a single nickname in bothLevel 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. |
|
| |
| RFC 9184 | BGP Extended Community Registries Update |
| |
|
|
This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading.
This document updates RFCs 7153 and 8955. |
|
| |
| RFC 9185 | DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange |
| |
| Authors: | P. Jones, P. Ellenbogen, N. Ohlmeier. |
| Date: | April 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9185 |
|
This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the KeyDistributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to theMedia Distributor. |
|
| |
| RFC 9186 | Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks |
| |
|
|
This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode(PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document. |
|
| |
| RFC 9187 | Sequence Number Extension for Windowed Protocols |
| |
|
|
Sliding window protocols use finite sequence numbers to determine segment placement and order. These sequence number spaces wrap around and are reused during the operation of such protocols. This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header. The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection. |
|
| |
| RFC 9188 | Generic Multi-Access (GMA) Encapsulation Protocol |
| |
|
|
A device can be simultaneously connected to multiple networks, e.g.,Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new lightweight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document 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 in order to experiment with the protocol. |
|
| |
| RFC 9189 | GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | S. Smyshlyaev, Ed., D. Belyavsky, E. Alekseev. |
| Date: | March 2022 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9189 |
|
This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations.
This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types. |
|
| |
| RFC 9190 | EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations ofEAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions ofTLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. |
|
| |
| RFC 9191 | Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods |
| |
| Authors: | M. Sethi, J. Preuß Mattsson, S. Turner. |
| Date: | February 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9191 |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem.This document looks at this problem in detail and describes the potential solutions available. |
|
| |
| RFC 9192 | Network Service Header (NSH) Fixed-Length Context Header Allocation |
| |
| Authors: | T. Mizrahi, I. Yerushalmi, D. Melman, R. Browne. |
| Date: | February 2022 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9192 |
|
The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MDType 0x1 uses a fixed-length Context Header. The allocation of thisContext Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.
Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability. |
|
| |
| RFC 9193 | Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format |
| |
|
|
The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binaryData Values. In order to facilitate processing of binary DataValues, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied. |
|
| |
| RFC 9194 | A YANG Module for IS-IS Reverse Metric |
| |
|
|
This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol. |
|
| |
| RFC 9195 | A File Format for YANG Instance Data |
| |
| Authors: | B. Lengyel, B. Claise. |
| Date: | February 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9195 |
|
There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable.This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. |
|
| |
| RFC 9196 | YANG Modules Describing Capabilities for Systems and Datastore Update Notifications |
| |
| Authors: | B. Lengyel, A. Clemm, B. Claise. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9196 |
|
This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities".
The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format.
The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to "Subscription toYANG Notifications for Datastore Updates" (RFC 8641). |
|
| |
| RFC 9197 | Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed., T. Mizrahi, Ed.. |
| Date: | May 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9197 |
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such asNetwork Service Header (NSH), Segment Routing, Generic NetworkVirtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. |
|
| |
| RFC 9198 | Advanced Unidirectional Route Assessment (AURA) |
| |
| Authors: | J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib. |
| Date: | May 2022 |
| Formats: | txt html pdf json xml |
| Updates: | RFC 2330 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9198 |
|
This memo introduces an advanced unidirectional route assessment(AURA) metric and associated measurement methodology based on the IPPerformance Metrics (IPPM) framework (RFC 2330). This memo updatesRFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies. |
|
| |
| RFC 9199 | Considerations for Large Authoritative DNS Server Operators |
| |
| Authors: | G. Moura, W. Hardaker, J. Heidemann, M. Davids. |
| Date: | March 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9199 |
|
Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.
It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.
This document is not an IETF consensus document: it is published for informational purposes. |
|
