**Session Date/Time:** 10 Mar 2022 15:00 # [T2TRG](../wg/t2trg.html) ## Summary The T2TRG held a pre-IETF 113 summary meeting, as the research group is not meeting face-to-face at IETF 113. The session focused on updates across various T2TRG activities and introduced new research directions. Key discussions included the launch of the SecCore initiative for IoT security, an in-depth look at amplification attacks on IoT, a novel approach to vulnerability management using the MUD (Manufacturer Usage Description) framework, updates on W3C Web of Things (WoT), the one Data Model (oneDM) and IoT Schema efforts, and a teaser for new work on secure awaken radio (SWAN/TINA). The group plans a dedicated work meeting in April/May to foster deeper research discussions, potentially on topics like digital twins. ## Key Discussion Points * **T2TRG Research Group Status:** * This was a summary meeting, not a face-to-face meeting at IETF 113. * A dedicated "work meeting" is planned for April/May to facilitate deeper research discussions, with digital twins identified as a potential initial topic. * The chairs are actively seeking collaborations for online meetings with SDOs (e.g., W3C, OMA), other alliances, and open-source communities. * **Document Updates:** "Restful Design for IoT" and "IoT and Identity" are progressing towards Research Group Last Call. Work continues on "Terminology and Processes for Initial Security Setup for IoT Devices." New drafts are anticipated on IoT information models ("IoT Information Model Standards Prescription" / "Semantic Landscape") and "Root of Trust Security" (Michael Richardson). * **Wishy Activity Update:** Much of the Wishy (hypermedia and semantic interoperability) work is now evolving within the ASDF and oneDM contexts. Recent discussions covered the relationship between Web of Things Thing Descriptions and Thing Models with SDF, as well as interworking and implementation of IPSSO, SDF, and DTDL. * **SecCore (Security for Constrained RESTful Environments) Initiative:** * Joran outlined a new T2TRG activity series, SecCore, to focus on security for CoAP-based applications and constrained restful environments. The name 'SecCore' (meaning dryness in Italian) was chosen. * The initiative stems from a CoRE WG breakout at IETF 113, recognizing the need for more dedicated work on CoAP security, building on existing IETF work (ACE, LAKEs, COSE) and external research. * SecCore aims to provide a space for researchers to collaborate, advance security research, and explain complex security results to a broader audience, with findings reported at T2TRG summary meetings. * Expected outputs include research papers, surveys, and discussions on topics spanning multiple IETF WGs or areas without an established home. * Initial candidate topics include amplification attacks and firmware updates using multicast. * **Consensus:** A sense of those present indicated strong support for the initiative. Colin Perkins cautioned regarding potential overlaps with existing IETF working group activities (e.g., IoT, IoTops, CFRG), which Joran acknowledged, confirming that the initial bolded topics are not currently adopted IETF WG items. * **Amplification Attacks on IoT:** * Joran presented amplification attacks as a primary topic for SecCore. * Distributed Denial of Service (DDoS) remains a significant and growing problem, with amplification attacks being a key vector. These involve an attacker sending a small message with a spoofed source IP to a server, which then generates a much larger response to the victim. * CoAP was used as an example, as it has been linked to significant amplification attacks (e.g., 320 Gbps in 2018), with attack patterns having waxed and waned. * Different types of CoAP amplification were described, including simple GETs, Observe (A * N factor), Multicast (A * M factor), and combinations thereof (A * M * N factor). * The IETF's QUIC protocol has a requirement for an amplification factor not exceeding 3. * **Discussion Points:** * Carsten Bormann emphasized the need to understand attacker dynamics (e.g., "fads" in attack vectors) and the reasons behind vulnerable deployments, even when security considerations are published (e.g., lack of communication, operational difficulties). Research involving interviews with deployers could provide valuable insights. * Michael McCool noted that discovery mechanisms, especially their initial, unauthenticated phases, could be vulnerable to amplification if they return large amounts of data. He suggested that authentication might need to be implemented earlier in the discovery process to minimize this risk. * Michael Richardson (via chat) suggested documenting insights for both protocol designers and implementers to improve "DDoS hygiene." * **Security Extensions for using MUD (Manufacturer Usage Description) for Fast Vulnerability Response (ISSUE Framework):** * Savio presented the "draft-morais-iotops-issue," a proposed framework to simplify vulnerability identification and coordinated response in domestic IoT networks. * The presentation highlighted the challenges for end-users in keeping up with new IoT vulnerabilities and the impracticality of traditional IDS/IPS solutions or anomaly detection (due to complexity, computational cost, or privacy concerns). * MUD (RFC 8520) was recognized as a valuable tool for defining expected device traffic and generating network communication graphs. However, MUD's limitation is its reliance on manufacturers, particularly for devices beyond their end-of-life. * The ISSUE framework proposes a "second security support" layer. It integrates MUD's output (communication graph) with "malicious traffic description files" (MDD) provided by security specialists. * MDD uses Access Control Lists (ACLs) and context information to describe malicious traffic, distinguishing between isolated attacks and malware. Processing occurs at the network edge to preserve user privacy. * Experiments using a Mirai variant in Docker containers (simulating vulnerable IoT devices) showed ISSUE's effectiveness in preventing DDoS packet generation compared to MUD-only or no protection. * **Next Steps:** Optimize anomaly detection algorithms using ISSUE as a filter, improve DNS traffic protection, conduct real-world deployment and testing, and develop an automatic MDD file generator. * **W3C Web of Things (WoT) Update:** * Michael McCool provided an update on the W3C WoT, which aims to adapt web technology to IoT by standardizing common metadata (Thing Description - TD) for device interfaces across various protocols. TDs are JSON-LD files with semantic support. * The WoT Discovery Specification (under review) proposes a two-phase strategy: unauthenticated "introductions" (e.g., via beacons, UPnP) and authenticated "exploration" for full metadata retrieval and queries (using JSON Path, XPath, Sparkle). Challenges exist with the standardization status and implementation cost of query languages. * **Key Blocker: Security.** Michael highlighted security as WoT's biggest challenge. Unlike the web's mature PKI and CA infrastructure, WoT currently lacks a common mechanism for establishing identities, keys, and onboarding, especially in segmented local networks where CAs may not be feasible. This is a significant barrier to out-of-the-box browser integration for IoT. * Commercial applications are emerging, with companies like Takenaka and Siemens using WoT for Building Information Systems (BIM), Netzo for dashboards, and Bosch/Oracle for Digital Twins. * **Research Needs:** Critical areas for future work include GIS integration (for smart city applications), standardized data management patterns for digital twins (shadows, simulation), and crucially, developing an IoT-friendly security infrastructure that can gain adoption from browser vendors. * **oneDM (one Data Model) and IoT Schema Update:** * Michael Koster provided an update on oneDM and IoT Schema efforts. * **oneDM:** The initiative has approximately 200 contributed definitions (from OMA, OCF) and is developing an operational process for model selection and convergence. The midterm goal is to achieve models that broadly work across different device ecosystems. A new mailing list (`1dm@groups.io`) has been established. * A key development is the creation of "bespoke repositories," allowing organizations to publish models under their own namespaces with CI tools, facilitating incremental convergence. * More models are being added, starting with Bluetooth Mesh characteristics and data types, to provide examples for composable models. * **SDF Pressure Test:** A "pressure test" is planned for SDF (Semantic Definition Format) to validate its capabilities for internal modularity, complex object composition, and extension points. * **IoT Schema:** This RDF framework for an event/action/property metamodel has a good set of definitions, is compatible with W3C, and has been used in plugfests. However, it has lacked active participation for model creation (a gap being filled by oneDM) and is currently dormant. There's no clear forward direction, though repurposing for physical domain modeling is a possibility. * **SWAN/TINA (Secure Awaken Radio Nudging) Teaser:** * Carsten Bormann gave a teaser for SWAN (Secure Awaken Radio Nudging), a research concept from 2016-2017 to protect battery-constrained IoT devices, particularly those using wake-on-radio, from unwanted network traffic. * The original concept involved a client using a token (derived from a device-issued grant) to send traffic through a last-hop router (acting as a Policy Enforcement Point). * Renewed interest is leading to a generalization of this concept, potentially named TINA (Token-based IN-network Authorization), which introduces roles like Device Authorization Manager (DAM) and Client Authorization Manager (CAM). This allows for delegation of tasks and greater flexibility in where policy decisions are made. * **Research Interest:** Key research areas include defining the right model, players, and security workflows, and developing efficient protocols that could potentially utilize in-network computing. Michael McCool noted some similarity to the more specialized Set Way mechanism. ## Decisions and Action Items * **Decision:** The T2TRG will launch the SecCore initiative to focus on security for constrained restful environments, aiming to gather researchers, progress research, and explain results relevant to IETF work. (00:10:02) * **Decision:** A dedicated T2TRG "work meeting" is planned for the April/May timeframe to foster deeper research discussions, with digital twins identified as a potential initial topic. (00:04:03) * **Action Item:** Interested individuals are encouraged to propose topics for SecCore, contact the chairs (Ari Keränen and Carsten Bormann), or use the T2TRG mailing list (`t2trg@irtf.org`) for involvement. (00:22:02) * **Action Item:** A "pen holder" (topic driver) is needed to lead the research on amplification attacks, starting with engaging the DDoS research community and exploring collaborations (e.g., with the Riot OS community). (00:38:00) * **Action Item:** Discussions on T2TRG document updates, Wishy activities, SecCore topics, Amplification Attacks, the ISSUE framework, W3C WoT, oneDM, IoT Schema, and SWAN/TINA are to continue on the T2TRG mailing list and in designated follow-up meetings/venues. (01:57:00) ## Next Steps * Announcements for upcoming SecCore meetings will be made via the Data Tracker and the T2TRG mailing list. * The T2TRG work meeting will be convened in April/May as planned. * Further discussions on the SWAN/TINA concept are expected to take place on the T2TRG mailing list. * Exploration of collaboration with DDoS research communities and open-source projects (e.g., Riot OS) will begin to better understand and mitigate amplification attacks. * The `draft-morais-iotops-issue` will continue to be refined, with further work on practical deployment and integration with anomaly detection. * W3C WoT will proceed with exploring identified gaps in use cases, GIS integration, data management patterns, and critically, developing a common security infrastructure that can be adopted by browser vendors. * oneDM will continue refining its convergence process, adding new models (e.g., from Bluetooth Mesh), and conducting an SDF pressure test to validate new features.