| |
|
| |
| | Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices |
| |
| | draft-ietf-opsawg-mud-tls-18.txt |
| | Date: |
23/08/2024 |
| | Authors: |
Tirumaleswar Reddy.K, Dan Wing, Blake Anderson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint. |
| | Authorized update to MUD URLs |
| |
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| | Operational Considerations for Use of DNS in IoT Devices |
| |
|
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 RFC 8520 Manufacturer Usage Description (MUD) definitions to control device access. Also, this document makes recommendations on when and how to use DNS names in MUD files. |
| | Ownership and licensing statements in YANG |
| |
| | draft-ietf-opsawg-ol-07.txt |
| | Date: |
21/10/2024 |
| | Authors: |
Eliot Lear, Carsten Bormann |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. |
| | PCAP Capture File Format |
| |
| | draft-ietf-opsawg-pcap-04.txt |
| | Date: |
04/08/2024 |
| | Authors: |
Guy Harris, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. |
| | Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 |
| |
| | draft-ietf-opsawg-tacacs-tls13-16.txt |
| | Date: |
12/12/2024 |
| | 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. |
| | Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements to export the On-Path Telemetry measured delay on the OAM transit and decapsulating nodes. |
| | Link-Layer Types for PCAP and PCAPNG Capture File Formats |
| |
|
This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. |
| | PCAP Next Generation (pcapng) Capture File Format |
| |
| | draft-ietf-opsawg-pcapng-02.txt |
| | Date: |
04/08/2024 |
| | Authors: |
Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. |
| | Export of UDP Options Information in IP Flow Information Export (IPFIX) |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. |
| | Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements |
| |
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. |
| | Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry |
| |
|
This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) Entities registry. Specifically, this document provides updates to fix shortcomings in the description of some Information Elements (IE), updates to ensure a consistent structure when citing an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. |
| | A YANG Data Model and RADIUS Extension for Policy-based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-06.txt |
| | Date: |
11/10/2024 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | A Common YANG Data Model for Attachment Circuits |
| |
| | draft-ietf-opsawg-teas-common-ac-13.txt |
| | Date: |
07/11/2024 |
| | Authors: |
Mohamed Boucadair, Richard Roberts, Oscar de Dios, Samier Barguil, Bo Wu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. |
| | YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) |
| |
|
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. |
| | A Network YANG Data Model for Attachment Circuits |
| |
|
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). |
| | A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits |
| |
|
The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to Attachment Circuits (ACs) that are created using the AC service ("ietf-ac-svc") and network ("ietf-ac-ntw") models. |
| | An Information Model for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-04.txt |
| | Date: |
21/10/2024 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
The primary function of a network is to transport and deliver packets according to service level objectives. Understanding both where and why packet loss occurs within a network is essential for effective network operation. Device-reported packet loss provides the most direct signal for network operations to identify the customer impact resulting from unintended packet loss. This document defines an information model for packet loss reporting, which classifies these signals to enable automated network mitigation of unintended packet loss. |
| | Guidelines for Characterizing "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates RFC 6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC 6291. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
| | draft-ietf-opsawg-ipfix-alt-mark-01.txt |
| | Date: |
03/11/2024 |
| | Authors: |
Thomas Graf, Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Massimo Nilo |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
| | draft-ietf-opsawg-ipfix-gtpu-02.txt |
| | Date: |
16/12/2024 |
| | Authors: |
Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Benoit Claise, Vyasraj Satyanarayana |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
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. |