Helvede

1 post1 participant0 posts today

Max ResingJust wanted to share some thoughts on <a href="https://infosec.exchange/tags/RFC9715" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC9715</a> - an <a href="https://infosec.exchange/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> that defines standards on reducing the <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DNS</a> issue of IP fragmentation over <a href="https://infosec.exchange/tags/UDP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#UDP</a>. It's not a long read, but a good one for everyone who understands the issues of large UDP responses on the <a href="https://infosec.exchange/tags/Internet" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Internet</a>. A great leap forward to (hopefully) reduce the reflection/amplification <a href="https://infosec.exchange/tags/DDoS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DDoS</a> potential of DNS.Just today I learned that <a href="https://infosec.exchange/tags/Google" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Google</a> will configure their public DNS resolvers to limit to ~1400 bytes (smaller adjustments expected while figuring out the sweet spot in production). From now on, DNS responses which exceed this limit will have the truncated flag set instructing the client to resolve back to <a href="https://infosec.exchange/tags/TCP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TCP</a>. <a href="https://infosec.exchange/tags/ipv4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ipv4</a> <a href="https://infosec.exchange/tags/ipv6" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ipv6</a> <a href="https://infosec.exchange/tags/ietf" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ietf</a>

RFC EditorRFC 9752: Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE, C. Li, et al., <a href="https://www.rfc-editor.org/info/rfc9752" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9752</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in stateful Path Computation Element (PCE) 1/3

RFC EditorRFC 9764: Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets, J. Haas, et al., <a href="https://www.rfc-editor.org/info/rfc9764" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9764</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know not only that the path between two systems is 1/3

RFC EditorRFC 9719: YANG Data Model for Routing in Fat Trees (RIFT), Z. Zhang, et al., <a href="https://www.rfc-editor.org/info/rfc9719" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9719</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document defines a YANG data model for the configuration and management of the Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1, which is defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 1/2

RFC EditorRFC 9696: Routing in Fat Trees (RIFT) Applicability and Operational Considerations, Y. Wei, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9696" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9696</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document discusses the properties, applicability, and operational considerations of Routing in Fat Trees (RIFT) in different network scenarios with the intention of providing a rough guide on how RIFT can be deployed to simplify routing 1/2

RFC EditorRFC 9692: RIFT: Routing in Fat Trees, T. Przygienda, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9692" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9692</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP 1/2

RFC EditorRFC 9759: Unified Time Scaling for Temporal Coordination Frameworks, K. Kuhns, <a href="https://www.rfc-editor.org/info/rfc9759" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9759</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the 1/2

Stéphane BortzmeyerRFC 9726: Operational Considerations for Use of DNS in IoT DevicesLes objets connectés sont une source de risques de sécurité. Pour les limiter, le RFC 8250 normalisait le format <a href="https://mastodon.gougere.fr/tags/MUD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MUD</a>, pour que le fournisseur du machin connecté documente les accès au réseau de l'objet. Dans un fichier MUD, les services avec lesquels l'objet communique sont indiqués par un nom de domaine. Le <a href="https://mastodon.gougere.fr/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#DNS</a> a quelques subtilités, décrites dans ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a>.<a href="https://www.bortzmeyer.org/9726.html" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.bortzmeyer.org/9726.html</a>

RFC EditorRFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices, M. Richardson, et al., <a href="https://www.rfc-editor.org/info/rfc9726" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9726</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 1/2

RFC EditorRFC 9778: IANA Considerations for Internet Group Management Protocols, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9778" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9778</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document specifies revised IANA considerations for the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This document specifies the guidance provided to IANA to manage values associated with various fields 1/2

RFC EditorRFC 9777: Multicast Listener Discovery Version 2 (MLDv2) for IPv6, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9777" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9777</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those 1/3

RFC EditorRFC 9776: Internet Group Management Protocol, Version 3, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9776" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9776</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report 1/3

RFC EditorRFC 9628: RTP Payload Format for VP9 Video, J. Uberti, et al., <a href="https://www.rfc-editor.org/info/rfc9628" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9628</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability as it supports applications from low bitrate peer-to-peer usage to high bitrate video conferences. It includes provisions for temporal and spatial scalability. This 1/2

RFC EditorRFC 9627: The Layer Refresh Request (LRR) RTCP Feedback Message, J. Lennox, et al., <a href="https://www.rfc-editor.org/info/rfc9627" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9627</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This memo describes the RTCP Payload-Specific Feedback Message Layer Refresh Request (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. This document also defines its use with several RTP payloads for scalable 1/2

RFC EditorRFC 9626: Video Frame Marking RTP Header Extension, M. Zanaty, et al., <a href="https://www.rfc-editor.org/info/rfc9626" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9626</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted and essential when the 1/2

RFC EditorRFC 9732: A Framework for NRP-Based Enhanced Virtual Private Networks, J. Dong, et al., <a href="https://www.rfc-editor.org/info/rfc9732" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9732</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). 1/3

RFC EditorRFC 9731: A YANG Data Model for Virtual Network (VN) Operations, Y. Lee, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9731" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9731</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This 1/2

RFC EditorRFC 9747: Unaffiliated Bidirectional Forwarding Detection (BFD) Echo, W. Cheng, et al., <a href="https://www.rfc-editor.org/info/rfc9747" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9747</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document specifies an extension to the Bidirectional Forwarding Detection (BFD) protocol that enables the use of the BFD Echo function without the need for an associated BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of 1/3

RFC EditorRFC 9754: Extensions for Opening and Delegating Files in NFSv4.2, T. Haynes, et al., <a href="https://www.rfc-editor.org/info/rfc9754" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9754</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This delegation provides the client the right to authoritatively cache metadata on the file locally. This document presents several extensions for 1/2

RFC EditorRFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP), S. Garcia Murillo, et al., <a href="https://www.rfc-editor.org/info/rfc9725" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.rfc-editor.org/info/rfc9725</a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RFC</a> This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or Content Delivery Networks (CDNs). This document updates RFCs 8840 and 8842. This document is a product of the WebRTC Ingest Signaling over 1/2

Recent searches

Search options

Administered by:

Server stats:

#rfc