Internet Drafts - IDs for Apr/2025

Index - Month Index of IDs

All IDs - sorted by date)

03/04/2025

	DNS over CoAP (DoC)
	draft-ietf-core-dns-over-coap-14.txt   Date: 03/04/2025   Authors: Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch   Working Group: Constrained RESTful Environments (core)	This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT).
	COSE Receipts
	draft-ietf-cose-merkle-tree-proofs-10.txt   Date: 03/04/2025   Authors: Orie Steele, Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet   Working Group: CBOR Object Signing and Encryption (cose)	COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162.
	DNSSEC Cryptographic Algorithm Recommendation Update Process
	draft-ietf-dnsop-rfc8624-bis-09.txt   Date: 03/04/2025   Authors: Wes Hardaker, Warren Kumari   Working Group: Domain Name System Operations (dnsop)	The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates RFC8624 by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC8624 to an IANA registry. This is done both to allow the list to be more easily updated, and to allow the list to be more easily referenced. Future extensions to this registry can be made under new, incremental update RFCs. This document also incorporates the revised IANA DNSSEC considerations from [RFC9157]. The document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in RFC8624; that is the work of future documents.
	Deprecating the use of SHA-1 in DNSSEC signature algorithms
	draft-ietf-dnsop-must-not-sha1-05.txt   Date: 03/04/2025   Authors: Wes Hardaker, Warren Kumari   Working Group: Domain Name System Operations (dnsop)	This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNSKEY and RRSIG records. It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms.
	Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
	draft-ietf-httpbis-optimistic-upgrade-03.txt   Date: 03/04/2025   Authors: Benjamin Schwartz   Working Group: HTTP (httpbis)	In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.
	Applicability of Interfaces to Network Security Functions to Network-Based Security Services
	draft-ietf-i2nsf-applicability-19.txt   Date: 03/04/2025   Authors: Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares, Diego Lopez   Working Group: Interface to Network Security Functions (i2nsf)	This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines.
	Segment Routing Path MTU in BGP
	draft-ietf-idr-sr-policy-path-mtu-11.txt   Date: 03/04/2025   Authors: Cheng Li, Yongqing Zhu, Ahmed El Sawaf, Zhenbin Li   Working Group: Inter-Domain Routing (idr)	Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies.
	Encrypted ESP Echo Protocol
	draft-ietf-ipsecme-encrypted-esp-ping-00.txt   Date: 03/04/2025   Authors: Antony Antony, Steffen Klassert   Working Group: IP Security Maintenance and Extensions (ipsecme)	This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED.
	List Pagination for YANG-driven Protocols
	draft-ietf-netconf-list-pagination-07.txt   Date: 03/04/2025   Authors: Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li   Working Group: Network Configuration (netconf)	In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists.
	NETCONF Extensions to Support List Pagination
	draft-ietf-netconf-list-pagination-nc-07.txt   Date: 03/04/2025   Authors: Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li   Working Group: Network Configuration (netconf)	This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination.
	RESTCONF Extensions to Support List Pagination
	draft-ietf-netconf-list-pagination-rc-08.txt   Date: 03/04/2025   Authors: Kent Watsen, Qin WU, Per Andersson, Olof Hagsand, Hongwei Li   Working Group: Network Configuration (netconf)	This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists.
	Intel Profile for Remote Attestation
	draft-cds-rats-intel-corim-profile-04.txt   Date: 03/04/2025   Authors: James Beaney, Yogesh Deshpande, Andrew Draper, Vincent Scarlata, Ned Smith   Working Group: Individual Submissions (none)	This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes apticulareplication of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers.
	Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces
	draft-templin-6man-omni3-48.txt   Date: 03/04/2025   Authors: Fred Templin   Working Group: Individual Submissions (none)	Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces.
	Automatic Extended Route Optimization (AERO)
	draft-templin-6man-aero3-41.txt   Date: 03/04/2025   Authors: Fred Templin   Working Group: Individual Submissions (none)	This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others.
	IPv6 Addresses for Ad Hoc Networks
	draft-templin-6man-mla-27.txt   Date: 03/04/2025   Authors: Fred Templin   Working Group: Individual Submissions (none)	Ad Hoc networks present an IPv6 addressing challenge due to the undetermined neighborhood properties of their interfaces. IPv6 nodes assign IPv6 addresses to their Ad Hoc networks that must be locally unique. IPv6 nodes must therefore be able to assign topology- independent addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type that nodes can autonomously assign for use over Ad-Hoc networks.
	CATS BGP Extension
	draft-ll-idr-cats-bgp-extension-01.txt   Date: 03/04/2025   Authors: Cheng Li, Peng Liu   Working Group: Individual Submissions (none)	CATS (Computing-Aware Traffic Steering) is a traffic engineering approach that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a service contact instance. This document defines the control plane BGP extension for CATS (Computing-Aware Traffic Steering).
	Extensible Delegation for DNS
	draft-homburg-deleg-01.txt   Date: 03/04/2025   Authors: Philip Homburg, Tim Wicinski, Jesse van Zutphen, Willem Toorop   Working Group: Individual Submissions (none)	This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with resource record sets placed below a _deleg label in the apex of the delegating zone. This authoritative delegation point can be aliased to other names using CNAME and DNAME. This document proposes a new DNS resource record type, IDELEG, which is based on the SVCB and inherits extensibility from it. IDELEG RRsets containing delegation information will be returned in the authority section in referral responses from supportive authoritative name servers. Lack of support in the authoritative name servers, forwarders or other components, does not obstruct obtaining the delegation information for resolvers, as it is originally authoritative information that can be queried for directly. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed on the authoritative name servers.
	Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3
	draft-ietf-opsawg-tacacs-tls13-19.txt   Date: 03/04/2025   Authors: Thorsten Dahm, John Heasley, dcmgash@cisco.com, Andrej Ota   Working Group: Operations and Management Area Working Group (opsawg)	The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol provides device administration for routers, network access servers and other networked computing devices via one or more centralized TACACS+ servers. This document adds Transport Layer Security (TLS 1.3) support to TACACS+ and obsoletes former inferior security mechanisms. This document updates RFC8907.
	Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
	draft-ietf-pce-segment-routing-policy-cp-26.txt   Date: 03/04/2025   Authors: Mike Koldychev, Siva Sivabalan, Samuel Sidor, Colby Barth, Shuping Peng, Hooman Bidgoli   Working Group: Path Computation Element (pce)	A Segment Routing (SR) Policy is an ordered list of instructions, called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6).
	Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements
	draft-ietf-savnet-intra-domain-problem-statement-14.txt   Date: 03/04/2025   Authors: Dan Li, Jianping Wu, Lancheng Qin, Mingqing(Michael) Huang, Nan Geng   Working Group: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)	This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements.
	Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)
	draft-ietf-spring-srv6-path-segment-12.txt   Date: 03/04/2025   Authors: Cheng Li, Weiqiang Cheng, Mach Chen, Dhruv Dhody, Yongqing Zhu   Working Group: Source Packet Routing in Networking (spring)	Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment Identifier (PSID) has been defined to identify an SR path in SR-MPLS networks, and is used for various use- cases such as end-to-end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the PSID to identify an SRv6 path in an IPv6 network.
	A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
	draft-ietf-teas-5g-ns-ip-mpls-18.txt   Date: 03/04/2025   Authors: Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras   Working Group: Traffic Engineering Architecture and Signaling (teas)	Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks.
	A well-known URI for publishing service parameters
	draft-ietf-tls-wkech-07.txt   Date: 03/04/2025   Authors: Stephen Farrell, Rich Salz, Benjamin Schwartz   Working Group: Transport Layer Security (tls)	We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too.
	TLS 1.2 is in Feature Freeze
	draft-ietf-tls-tls12-frozen-08.txt   Date: 03/04/2025   Authors: Rich Salz, Nimrod Aviram   Working Group: Transport Layer Security (tls)	Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.

02/04/2025

	Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
	draft-ietf-ipsecme-ikev2-qr-alt-08.txt   Date: 02/04/2025   Authors: Valery Smyslov   Working Group: IP Security Maintenance and Extensions (ipsecme)	An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations.
	Fully-Specified Algorithms for JOSE and COSE
	draft-ietf-jose-fully-specified-algorithms-09.txt   Date: 02/04/2025   Authors: Michael Jones, Orie Steele   Working Group: Javascript Object Signing and Encryption (jose)	This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers.
	JOSE: Deprecate 'none' and 'RSA1_5'
	draft-ietf-jose-deprecate-none-rsa15-02.txt   Date: 02/04/2025   Authors: Neil Madden   Working Group: Javascript Object Signing and Encryption (jose)	This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations should meet.
	A YANG Data Model for OSPF Segment Routing over the MPLS Data Plane
	draft-ietf-ospf-sr-yang-41.txt   Date: 02/04/2025   Authors: Yingzhen Qu, Acee Lindem, Zhaohui Zhang, Helen Chen   Working Group: Link State Routing (lsr)	This document defines a YANG data model that can be used to manage OSPF Extensions for Segment Routing over the MPLS data plane.
	RESTCONF Client and Server Models
	draft-ietf-netconf-restconf-client-server-41.txt   Date: 02/04/2025   Authors: Kent Watsen   Working Group: Network Configuration (netconf)	This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft * JJJJ --> the assigned RFC value for draft-ietf-netconf-udp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-04-02 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log
	Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX
	draft-ietf-sfc-nsh-ecn-support-15.txt   Date: 02/04/2025   Authors: Donald Eastlake, Bob Briscoe, Shunwan Zhuang, Andrew Malis, Xinpeng Wei   Working Group: Individual Submissions (none)	Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol.
	Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC
	draft-fregly-dnsop-slh-dsa-mtl-dnssec-04.txt   Date: 02/04/2025   Authors: Andrew Fregly, Joe Harvey, Burt Kaliski, Duane Wessels   Working Group: Individual Submissions (none)	This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval.
	LISP Multicast Deployment Experience
	draft-vgovindan-lisp-multicast-deploy-01.txt   Date: 02/04/2025   Authors: Vengada Govindan, Marcin Hamroz, Jaroslaw Gawron   Working Group: Individual Submissions (none)	We present our experiences in supporting deployments of LISP Multicast using unicast and multicast underlays. This document details design considerations that can be useful for anyone interested in deploying LISP multicast services over IP networks.
	CBOR Core (CBOR/c)
	draft-rundgren-cbor-core-01.txt   Date: 02/04/2025   Authors: Anders Rundgren   Working Group: Individual Submissions (none)	This document defines CBOR Core (CBOR/c), a profile of CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. To foster interoperability, deterministic encoding is mandated. Furthermore, the document outlines how deterministic encoding combined with enhanced CBOR tools, enable cryptographic methods like signing and hashing, to optionally use "raw" (non-wrapped) CBOR data as input. This document mainly targets CBOR tool developers.

01/04/2025

	A Voucher Artifact for Bootstrapping Protocols
	draft-ietf-anima-rfc8366bis-14.txt   Date: 01/04/2025   Authors: Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert, Qiufang Ma   Working Group: Autonomic Networking Integrated Model and Approach (anima)	This document defines a strategy to securely assign a Pledge to an owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, includes a number of desired extensions into the YANG. The voucher request defined in RFC8995 is also now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995.
	CBOR Common Deterministic Encoding (CDE)
	draft-ietf-cbor-cde-10.txt   Date: 01/04/2025   Authors: Carsten Bormann   Working Group: Concise Binary Object Representation Maintenance and Extensions (cbor)	CBOR (STD 94, RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, providing some flexibility for application specific decisions. To facilitate Deterministic Encoding to be offered as a selectable feature of generic encoders, the present document defines a CBOR Common Deterministic Encoding (CDE) that can be shared by a large set of applications with potentially diverging detailed requirements. It also defines the term "Basic Serialization", which stops short of the potentially more onerous requirements that make CDE fully deterministic, while employing most of its reductions of the variability needing to be handled by decoders.
	Partially Blind RSA Signatures
	draft-irtf-cfrg-partially-blind-rsa-01.txt   Date: 01/04/2025   Authors: Ghous Amjad, Scott Hendrickson, Christopher Wood, Kevin Yeo   Working Group: Crypto Forum (cfrg)	This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. 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/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa.
	ALPN ID Specification for CoAP over DTLS
	draft-ietf-core-coap-dtls-alpn-04.txt   Date: 01/04/2025   Authors: Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch   Working Group: Constrained RESTful Environments (core)	This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services.
	ML-DSA for JOSE and COSE
	draft-ietf-cose-dilithium-06.txt   Date: 01/04/2025   Authors: Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans   Working Group: CBOR Object Signing and Encryption (cose)	This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204.
	Reliable and Available Wireless (RAW) Technologies
	draft-ietf-raw-technologies-16.txt   Date: 01/04/2025   Authors: Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas   Working Group: Deterministic Networking (detnet)	This document surveys the short and middle range radio technologies that are suitable to provide a Deterministic Networking / Reliable and Available Wireless (RAW) service over, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of its time of publication. The studied technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). Those technologies were selected as part of the RAW WG formation and listed in the WG charter.
	The DRIP DET public Key Infrastructure
	draft-ietf-drip-dki-07.txt   Date: 01/04/2025   Authors: Robert Moskowitz, Stuart Card   Working Group: Drone Remote ID Protocol (drip)	The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size.
	A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane
	draft-ietf-isis-sr-yang-26.txt   Date: 01/04/2025   Authors: Stephane Litkowski, Yingzhen Qu, Pushpasis Sarkar, Helen Chen, Jeff Tantsura   Working Group: Link State Routing (lsr)	This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane.
	Extensions to the Access Control Lists (ACLs) YANG Model
	draft-ietf-netmod-acl-extensions-16.txt   Date: 01/04/2025   Authors: Oscar de Dios, Samier Barguil, Mohamed Boucadair, Qin WU   Working Group: Network Modeling (netmod)	RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers.
	A Decent LISP Mapping System (LISP-Decent)
	draft-farinacci-lisp-decent-17.txt   Date: 01/04/2025   Authors: Dino Farinacci, Colin Cantrell   Working Group: Individual Submissions (none)	This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. The intended status for this document is Informational RFC and should be used by LISP-Decent implementations to interoperate with each other.
	The Incident Detection Message Exchange Format version 2 (IDMEFv2)
	draft-lehmann-idmefv2-05.txt   Date: 01/04/2025   Authors: Gilles Lehmann   Working Group: Individual Submissions (none)	The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765.
	IGP Color-Aware Shortcut
	draft-cheng-lsr-igp-shortcut-enhancement-08.txt   Date: 01/04/2025   Authors: Weiqiang Cheng, Liyan Gong, Changwang Lin, Ran Chen   Working Group: Individual Submissions (none)	IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document specifies the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors.
	Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS
	draft-lehmann-idmefv2-https-transport-04.txt   Date: 01/04/2025   Authors: Gilles Lehmann   Working Group: Individual Submissions (none)	The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767.
	Hash-based Signatures: State and Backup Management
	draft-wiggers-hbs-state-02.txt   Date: 01/04/2025   Authors: Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis   Working Group: Individual Submissions (none)	Stateful Hash-Based Signature Schemes (S-HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large- scale quantum computers. Unlike conventional stateless digital signature schemes, S-HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered.
	Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol
	draft-xsaopig-nmop-service-flow-modal-mapping-02.txt   Date: 01/04/2025   Authors: Huanxing Zhu   Working Group: Individual Submissions (none)	This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements.
	Update to RFC 8717: IETF Administrative Terminology
	draft-rsalz-8717-update-01.txt   Date: 01/04/2025   Authors: Rich Salz   Working Group: Individual Submissions (none)	RFC 8717 updated several RFCs pertaining to the organization of the IETF to use the term "Managing Director, IETF Secretariat" (MDS). As that term does not accurately reflect the organization or roles of the IETF staff, the MDS term is no longer relevant. This document removes mention of particular staff roles, and instead updates the source documents so that the job to be done, and who the responsible entity is, are described.
	An HTTP Status Code to Indicate Request Noncomformity While Still Making Best-Effort Response
	draft-sbarta-tolerating-00.txt   Date: 01/04/2025   Authors: Silas Barta   Working Group: Individual Submissions (none)	This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource was accessed in a nonconforming manner but the request will be tolerated with reservation, while directing the client adhere to relevant protocols.
	DomainAuth Version 1
	draft-narea-domainauth-00.txt   Date: 01/04/2025   Authors: Gus Narea   Working Group: Individual Submissions (none)	This document defines DomainAuth, a protocol to attribute digital signatures to domain names in such a way that verification can occur entirely offline without a prior distribution of public keys. Each signature is distributed as part of a self-contained "signature bundle" that encapsulates a complete chain of trust comprising: (1) a DNSSEC chain from the root zone to a TXT record containing a public key or its digest, (2) an X.509 certificate chain from the key specified in the TXT record to the final signing key, and (3) the digital signature in the form of a CMS SignedData structure. Finally, signatures can be attributed to the domain name itself (e.g. "example.com") or specific users (e.g. "alice" of "example.com").
	NAT Sub Address Protocol
	draft-mclarty-nat-sub-address-protocol-00.txt   Date: 01/04/2025   Authors: Daniel McLarty   Working Group: Individual Submissions (none)	This document defines the NAT Sub-Address Protocol (NATSAP), a Layer 5 encapsulation protocol designed to facilitate seamless bidirectional communication with devices behind Carrier-Grade NAT (CG NAT). NATSAP introduces dynamic sub-addresses assigned by the NAT router, which external clients can use alongside the public IP to route traffic back to internal devices without requiring traditional port forwarding. This document also defines the Dynamic Sub-Address Assignment Protocol (DSAAP), to facilitate the acquiring of a NATSAP Sub-Address. The protocol offers backward compatibility with existing IPv4 infrastructure, efficient DNS-based service discovery, and simple, stateless mapping. By encapsulating application-layer traffic, NATSAP enables direct communication with devices behind NATs using a standardized socket notation and DNS records.
	ML-DSA for Web Authentication
	draft-vitap-ml-dsa-webauthn-00.txt   Date: 01/04/2025   Authors: Aditya Mitra, Sibi Chakkaravarthy, Anisha Ghosh, Devi VS   Working Group: Individual Submissions (none)	This document describes implementation of Passwordless authentication in Web Authentication (WebAuthn) using Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204.
	A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)
	draft-ietf-opsawg-secure-tacacs-yang-06.txt   Date: 01/04/2025   Authors: Mohamed Boucadair, Bo Wu, Guangying Zheng, Zitao Wang   Working Group: Operations and Management Area Working Group (opsawg)	This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105.
	Convergence of Congestion Control from Retained State
	draft-ietf-tsvwg-careful-resume-16.txt   Date: 01/04/2025   Authors: Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema   Working Group: Transport and Services Working Group (tsvwg)	This document specifies a cautious method for IETF transports that enables fast startup of CC for a wide range of connections. It reuses a set of computed CC parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the CC behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of Careful Resume impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.

---