| |
|
| |
| | MISP taxonomy format |
| |
|
This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. |
| | BGP SR Policy Extensions for template |
| |
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. |
| | CoAP in Space |
| |
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. |
| |
|
| |
| | External References to Values in CBOR Diagnostic Notation (EDN) |
| |
| | draft-ietf-cbor-edn-e-ref-01.txt |
| | Date: |
29/12/2024 |
| | Authors: |
Carsten Bormann |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. |
| | BGP SR Policy Extensions for metric |
| |
|
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. |
| | Unicast Use of the Formerly Reserved 240/4 |
| |
|
This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Unicast Use of the Lowest Address in an IPv4 Subnet |
| |
|
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. |
| | Flow Measurement in IPv6 Network |
| |
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. |
| | Unicast Use of the Formerly Reserved 0/8 |
| |
|
This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Unicast Use of the Formerly Special-Cased 127/8 |
| |
|
This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. |
| | SRPM Path Consistency over SRv6 |
| |
|
TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light. |
| | Distributed Flow Measurement in IPv6 |
| |
|
In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller. |
| | Intra-domain SAV Support via BGP |
| |
|
This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes. |
| | BGP SR Policy Extensions for Weight Time Range |
| |
|
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 candidate paths, each consisting of one or more segment lists. In the scenario where there are multiple segment list paths, traffic load balancing can be achieved based on the weight value assigned to each path. Typically, the weight value for each path is fixed. This document defines an extension of BGP SR Policy for setting the weight value for each path based on time range. |
| | Sockets API Extensions for In-kernel QUIC Implementations |
| |
|
This document describes a mapping of In-kernel QUIC Implementations into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new QUIC features, and a consolidated error and event notification scheme. In-kernel QUIC enables usage for both userspace applications and kernel consumers. |
| | Public Key Hash for Local Domains |
| |
|
This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake. |
| |
|
| |
| | Adaptive IPv4 Address Space |
| |
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. |
| | IGP Extensions for Deterministic Traffic Engineering |
| |
|
This document describes IGP extensions to support Traffic Engineering (TE) of deterministic routing, by specifying new information that a router can place in the advertisement of neighbors. This information describes additional details regarding the state of the network that are useful for deterministic traffic engineering path computations. |
| | Research Agenda for a Post-Quantum DNSSEC |
| |
|
This document describes a notional research agenda for collaborative multi-stakeholder research related to a future post-quantum DNSSEC ecosystem. It is inspired by the anticipation that adoption of Post- Quantum signature algorithms will have enough operational impact on DNSSEC that either DNS protocol enhancements will be needed, or DNS will move away from UDP as the prevalent DNS transport, or a combination of both will be needed. Some members of the DNS technical community have even suggested evaluating alternatives to DNSSEC and potentially adopting an alternative protocol or practices to assure the integrity of DNS responses. Given the potential impact of such changes on the DNS ecosystem, the authors believe collaborative multi-stakeholder research into the impact of proposed changes should be performed to inform adoption and standardization activities. |
| | PCRP Webhook Specification |
| |
|
This document defines the PCRP (Ping, Challenge, Resolve, Product) Specification for Webhook events in a standardized way. It is specifically designed to address the challenges faced in current webhook event implementations, which lack consistency and a defined flow. PCRP introduces a new header X-PCRP-Type to indicate the step of the process, and its values include ping, challenge, resolve, and product. |
| |
|
| |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. |
| | Randomized and Changing MAC Address: Context,Network Impacts,and Use Cases |
| |
| | draft-ietf-madinas-use-cases-19.txt |
| | Date: |
20/12/2024 |
| | Authors: |
Jerome Henry, Yiu Lee |
| | Working Group: |
MAC Address Device Identification for Network and Application Services (madinas) |
|
To limit the privacy issues created by the association between a device, its traffic, its location, and its user in [IEEE_802] networks, client and client Operating System vendors have started implementing MAC address randomization. This technology is particularly important in Wi-Fi [IEEE_802.11] networks due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC address randomization purposes. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines two existing frameworks to maintain user privacy while preserving user quality of experience and network operation efficiency. |
| | OAuth Status Assertions |
| |
|
Status Assertion is a signed object that demonstrates the validity status of a Digital Credential. These assertions are periodically provided to Holders, who can present these to Credential Verifier along with the corresponding Digital Credentials. The approach outlined in this document makes the Credential Verifier able to check the status, such as the non-revocation, of a Digital Credential without requiring to query any third-party entities. |
| | Trust is non-negotiable |
| |
|
This document considers proposals to enable the negotiation of trust anchors in TLS. It makes three basic arguments: that trust negotiation is not helpful in addressing the problems it claims to address, that trust negotiation instead comes with material harms to the critical trust infrastructure of the Internet, and that the proposed mechanisms for deploying trust negotiation are unworkable. This draft goes on to discuss simpler and more effective solutions to these problems. |
| |
|
| |
| | SNAC Router Flag in ICMPv6 Router Advertisement Messages |
| |
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices. |
| | BIER Penultimate Hop Popping |
| |
|
This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks. |
| | Use Cases for In-Network Computing |
| |
| | draft-irtf-coinrg-use-cases-07.txt |
| | Date: |
04/12/2024 |
| | Authors: |
Ike Kunze, Klaus Wehrle, Dirk Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio |
| | Working Group: |
Computing in the Network Research Group (coinrg) |
|
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. It is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard. |