The Internet Engineering Task Force (IETF) is holding a hackathon to encourage developers and subject matter experts to discuss, collaborate, and develop utilities, ideas, sample code, and solutions that show practical implementations of IETF standards.
When: 18 - 19 July 2026 (Saturday - Sunday)
Where: Hilton Vienna Park
Room: Grand Klimt Hall 1/2
Sign up for the Hackathon
View the list of registered:
Keep up to date by subscribing to the IETF Hackathon email list.
The IETF Hackathon is free to attend and is open to everyone. It is a collaborative event, not a competition. Any competition is friendly and in the spirit of advancing the pace and relevance of new and evolving internet standards.
¶ Agenda
Subject to Change
Hackathon (all times are GMT+2)
¶ Saturday, 18 July
- 09:30 : Room open for setup by project champions
- 10:00 : Room open for all - pastries and coffee provided
- 10:30 : Hackathon kickoff
- 10:45 : Form teams, see Team Schedule
- 12:30 : Lunch provided
- 15:30 : Afternoon break - snacks provided
- 18:30 : Dinner provided
- 20:30 : Room closes
¶ Sunday, 19 July
- 08:30 : Room opens - pastries and coffee provided
- 11:30 : Lunch provided
- 12:30 : Hacking stops, prepare brief presentation of project
- 13:00 : Project results presentations
- 15:00 : Hackathon ends
- 16:00 : Tear down complete
Related activities before and after the Hackathon weekend
¶ Hackdemo Happy Hour
- Share your Hackathon project with the IETF community
- Monday, 20 July, Time: 18:30 - 19:30, Room: Park Ensemble
- View the schedule or reserve space for your team/project
- Reservations for space must be made by 13:00, Monday 20 July
¶ Shared Workspace
- Space for groups to gather and collaborate on running code
- Monday - Friday, 20 - 24 July, Room: Lobby Bar Area
NOTE: You will need an IETF Datatracker account to login to the Hackathon Meetecho sessions.
When you register for the IETF Hackathon, you are sent a separate email to create an IETF Datatracker account if you don't already have one.
If you already have an IETF Datatracker account, please ensure that the email address with which you registered is associated with your Datatracker account.
If you received the email but the link to create an account has expired, please see the instructions below:
- Go to https://datatracker.ietf.org/accounts/create/
- Select "New Account" from the User menu at the top
- Enter the email address that you registered with for the Hackathon
- Follow the instructions in the email you receive
¶ Presentation and Meeting Materials
- You can share the code you're working on through the IETF Hackathon GitHub, or via the links provided in the project descriptions below.
- Request to be added to IETF GitHub organization by sending your GitHub ID to (hackathon-chairs@ietf.org).
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 13:00-15:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- The Hackathon Results presentations from Sunday, 13:00-15:00, are available on Datatracker:
¶ Participant Preparation and Prerequisites
¶ Project Teams and Champions
- Champions are the leads for individual projects in the Hackathon
- Champions are individuals familiar with a given technology who volunteer to help get others get up and running with that technology
- Before the Hackathon, champions should:
- Add information about your project to the list of Projects included in Hackathon
- Recruit participants from associated working groups, open source projects, etc. Announcing your projects via an email to (hackathon@ietf.org) can be helpful as well.
- Specify when and how the project team will meet on the Team Schedule
- At the Hackathon, champions should:
- Make themselves available to answer questions and help others
- Hack on things themselves in their copious free time
- Additional projects are welcome at any time. For any questions, contact the chairs at (hackathon-chairs@ietf.org)
¶ Choosing a Project
- Champions post and lead projects
- Details on each project and links to additional information for each project are in the list of Projects included in Hackathon
- How and when teams meet during the week is up to them and can be found in the Team Schedule.
- Familiarity with technology area(s) in which you plan to participate will certainly help
- It is perfectly fine, even encouraged, to work on multiple projects
¶ Lost & Found
- Participants looking for a team and champions wanting help on their projects are encouraged to visit the Lost & Found.
¶ Development Environment
- Bring a laptop on which you are comfortable developing software
- Some projects may require installing additional software or make use of VMs or containers
- Installing and becoming familiar with !VirtualBox, Vagrant, Docker or something similar may be helpful
- Specific coding languages are called out by some projects (e.g. Python, Go, Java, C++), but this is heavily dependent on the project(s) you choose
¶ Sharing Code
- Git/GitHub is commonly used for open source projects. Familiarizing yourself with it is recommended.
- An online tutorial is available here: Git Tutorial
- The IETF Hackathon GitHub organisation is used by some of the Hackathon projects to host their repositories.
- If you would like to have your project/code hosted here, send your GitHub ID and the name of your project via email to (hackathon-chairs@ietf.org)
¶ Project Presentations
- All teams have the opportunity to present what they did at the end of the Hackathon.
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 13:00-15:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- DO NOT WAIT until just before the start of the Hackathon project presentations to upload your presentation, as it may be lost in the chaos.
¶ Network
Access to the IETF network
Requests for networking capabilities beyond wireless access to the IETF network (e.g., wired ports, L2 access, prefix delegation) can be sent to support@ietf.org.
All requests are addressed on a best effort basis. Advance notice is appreciated and improves the odds of your request being fulfilled.
¶ Webex sessions for teams
Champions can request a Webex account they can use to schedule meetings for their team. These are similar to the Webex accounts allocated to working group chairs to be used for virtual interim meetings. An account can be requested by a team champion at any time. Accounts will remain active and available for the duration of the IETF meeting. Request your account HERE. In the request form, you can use your project name where it asks for "Working Group Name" ("Hackathon Project Name").
¶ Ongoing Communication
In addition to registering for the Hackathon and subscribing to the Hackathon list. It is recommended to monitor both the Hackathon wiki and the list as the Hackathon approaches, determine which project(s) are of interest to you, and reach out to the champions of those projects to determine how best to be involved and coordinate with the rest of the team working on each project.
Champions are welcome and encouraged to list times and mechanisms for collaborating with their team in the Team Schedule. Participants can use this page to determine how and when to reach other team members.
The Hackathon kickoff and the project results presentations can be joined via Meetecho. The Hackathon Zulip stream may be used for general and project specific communication.
¶ IPR and Code Contribution Guideline
All Hackathon participants are free to work on any code. The rules regarding that code are what each open source project and each participant's organization says they are. The code itself is not an IETF Contribution. However, discussions, presentations, demos, etc., during the Hackathon are IETF Contributions (similar to Contributions made in working group meetings). Thus, the usual IETF policies apply to these Contributions, including copyright, license, and IPR disclosure rules.
¶ Projects Included in Hackathon
Note, all projects are open to everyone. However, some champions have identified their projects as being particularly good for those who are new to the IETF or new to the Hackathon. These projects are marked with a star, i.e. *. If you are championing a project that is great for newcomers, please add a * at the end of your project name.
For inspiration and examples of previous Hackathon projects see the previous Hackathon page.
¶ RESTful Provisioning Protocol (RPP)
-
Champions
Maarten Wullink maarten.wullink@sidn.nl
Pawel Kowalik pawel.kowalik@denic.de -
Project Info
The RPP working group is focused on designing a new protocol for registering objects in a shared registry, as a possible alternative for EPP. This will result in a series of specifications known collectively as the RESTful Provisioning Protocol (RPP). -
Hackathon Plan
- Discuss/Develop/Validate current and future work
- Develop running code
- Other interesting ideas
-
Related documents
¶ Identifier Locator Network Protocol (ILNP)
-
Champions
- Saleem Bhatti saleem@st-andrews.ac.uk
- Rodney Grimes rgrimes@freebsd.org
- Alistair Woodman awoodman@netdef.org
-
Project Info
- https://ilnp.cs.st-andrews.ac.uk
- RFCs 6740(E) - 6748(E)
- The basic approach is to deprecate the concept of an IP Address and replace it with addressing using separate Locator and Identifier values, a pairing of which forms an Identifier-Locator Vector (ILV). Although the architectural concept is independent of any particular network protocol, our ongoing research work is based on realising ILNP on IPv6.
¶ Low-Power Wireless IPv6 Networking with Thread *
-
Champion
Stuart Cheshire <cheshire@apple.com> -
Thread Overview
Thread is a specification for how to carry IPv6 datagrams over a self-configuring mesh of low-power IEEE 802.15.4 wireless links. Stuart Cheshire gave a brief presentation about Thread at the IETF 119 IAB Open meeting in Brisbane. The Thread specification is developed and published by the Thread Group. There are several independent implementations of Thread, the main one being the OpenThread open source project. This Hackathon event is open to all — Thread Group membership is not required, though of course Thread Group members are also welcome to participate.
-
Participants and Project Info
- To avoid taking up too much space on the main Hackathon page, Thread participants and projects are listed separately on the Thread Projects page.
¶ Post-Quantum Cryptography (PQC) in X.509, Signatures, KEMs, CMS and protocols
-
Champion(s)
John Gray (john.gray@entrust.com)
Daniel Van Geest (Daniel.vangeest@cryptonext-security.com)
Mike Ounsworth (mike.ounsworth@crypticforest.ca)
Jean-Pierre Fiset (jp@crypto4a.com)
Massimiliano Pala (massimiliano.pala@wellsfargo.com) -
Draft Specifications
https://datatracker.ietf.org/doc/html/rfc9881
https://datatracker.ietf.org/doc/rfc9935/
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
https://datatracker.ietf.org/doc/rfc9629/
https://datatracker.ietf.org/doc/rfc9810/
https://www.ietf.org/id/draft-ietf-lamps-certdiscovery/
https://datatracker.ietf.org/doc/rfc9909/
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-sigs/ -
Project Info
Test interoperability of Post Quantum algorithms in x.509 structures (Certificates, keys, CMS and other drafts). This project started in November 2022 and continues to evolve. We currently have github automated tooling that automatically tests submitted artifacts allowing implementations to get immediate feedback on their compatibility. This allows us to test interoperability between different algorithm implementations, gain experience using these new algorithms, and provide feedback to the standards groups about practical usage.
A good starting place is our Github repository: https://github.com/IETF-Hackathon/pqc-certificates
For information on OIDs used to create interoperable structures, consult: https://github.com/IETF-Hackathon/pqc-certificates/blob/master/docs/oid_mapping.md
At IETF 126, we plan to add more automation and others are invited to test interoperability. FrodoKEM and Classic McEliece have been standardized at ISO, so participants are welcome to test those algorithms. Some experimentation with Merkle Tree Certificates is also being tested.
¶ YANG Data Model for Network Inventory (IVY) - 2
-
Champions
Nigel Davis <ndavis@ciena.com> -
Project Info
The IETF IVY WG has been developing models for network inventory. Following on from the successful IVY activity at the IETF 125 hackathon, this hackathon activity will again focus on the modelling of physical inventory. The intention is to have multiple players in both inventory system role and controller role where the inventory system player displays physical inventory detail provided via an IVY conformant interface from various controllers. -
Hackathon Objectives and Plan
The aim is to extend the participation, exercise more of the model and, especially, to:
-- Work with the latest ivy YANG and potentially previous versions
-- Demonstrate systems from various vendors can interoperate and convey inventory detail
-- Explore for missing detail and demonstrate interop with additional new properties
-- Compare with other inventory models (especially [TAPI (Linux Foundation)] (https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI)) and add further properties as appropriate again demonstrate interop
-- Prepare proposals for updates to IVY model -
Hackathon project slides
The slide pack IvyHackathon.pptx, shared with the TAPI team, provides further details. -
TIP MANTRA interest in IETF IVY Hackathon
Please see operator support for this Hackathon at TIP MANTRA interest in IETF IVY Hackathon -
Participants
Currently both Ciena and Cisco have committed to engage in the Hackathon activity on site. Other vendors are exploring possible engagement. -
Related documents etc.
Network Inventory YANG (Ivy)
A Base YANG Data Model for Network Inventory
network-inventory-yang
TAPI
¶ BRAID Phase 0: Structural Revocation Without OCSP, CRLs, or Short Lifetimes
- Champions
George Davey braid@cpu.io - Project Info
TLS revocation has never worked reliably at internet scale. OCSP soft-fails, CRLs go unchecked, and the industry's answer has been to shrink certificate lifetimes so a bad certificate expires before it matters. BRAID (draft-davey-tls-braid-00) takes the opposite approach: make freshness owner-controlled and structural, so a certificate stops validating the moment its owner stops authorizing it — no status responder, no revocation list, no 47-day treadmill.
This hackathon project builds the one piece that needs nothing new to run — Phase 0: a monitor that checks the Delegated Credential a TLS endpoint is using against a DNSSEC-signed, owner-published _braid Anchor. No TLS protocol changes, no browser changes, no public-CA or root-program changes. It runs today.
We'll be dogfooding on real infrastructure — live domains, a private CA, and origin-AS space we operate — rather than toy fixtures, so the results reflect what an actual operator would see.
Draft: draft-davey-tls-braid
Code: github.com/braid2026/braid (repo published before the event)
-
Hackathon goals
- Publish a DNSSEC-signed
_braidTXT-form Anchor listing hashes of the Delegated Credential public keys an owner authorizes. - Observe or retrieve the Delegated Credential in use at a TLS endpoint (negotiated, or via an out-of-band owner-published document where direct observation isn't available).
- Verify the credential's validity window is current and within the freshness bound (≤ 7 days).
- Compare the observed credential's public-key hash against the DNSSEC-validated Anchor.
- Emit clear monitor verdicts:
authorized,mismatch,stale,unknown,dnssec-failed. - Demonstrate revocation live: withdraw the Anchor entry and watch the endpoint go from
authorizedtomismatchwithin the record's TTL — no OCSP, no CRL, no CA involvement. - Map what later protocol pieces would belong where — TLS, LAMPS, DNSOP, SIDROPS.
- Publish a DNSSEC-signed
-
Optional stretch goal
- Add a second independent check: validate the endpoint's origin AS against RPKI, as a first look at BRAID's Routing strand alongside the Identity strand.
-
Expected outputs
- A small open-source monitor prototype.
- A sample
_braidTXT Anchor format others can test against. - Test output covering the authorized, unauthorized, stale, and revoked-mid-session cases.
- A short results talk: what worked, what broke, and which protocol gaps surfaced.
¶ Service Affinity Solution based on Transport Layer Security (TLS)
-
Champions
Aijun Wang (wangaj3@chinatelecom.cn) -
Project Info
This project aims to present a demo of the TLS-based service affinity solution. This proposal is designed for environments where operational simplicity and migration speed are paramount. It intentionally omits the path validation steps to minimize the latency of the migration process. Furthermore, it simplifies the trigger mechanism by using a new TLS alert, which is a direct and unambiguous signal. -
Related works
-
Service Affinity Solution based on Transport Layer Security (TLS): https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/
¶ AI based Network Management Agent (NMA)
- Champions
Xing Zhao (zhaoxing@caict.ac.cn)
Minxue Wang (wangminxue@chinamobile.com)
Bo Wu (lana.wubo@huawei.com)
Daniele Ceccarelli (dceccare@cisco.com)
Haomian Zheng (zhenghaomian@huawei.com)
Jin Zhou (zhou.jin6@zte.com.cn) - Project Info
The draft <AI based Network Management Agent(NMA): Concepts and Architecture> (https://datatracker.ietf.org/doc/draft-zhao-nmop-network-management-agent/) defines the Network Management Agent (NMA), an AI-driven entity that bridges the gap between service intent and network operations. It acts as the cognitive layer, autonomously decomposing intent, planning tasks, and making decisions, while leveraging SDN Controllers as the execution layer to enforce policies on the network infrastructure.
This project will produce a live demo of a single NMA agent. The focus is on validating NMA deployment and application in specific network domains, including but not limited to OTN (Optical Transport Network), SPN (Slicing Packet Network), etc. The demo will showcase how NMA integrates with SDN Controllers to achieve intent-based closed-loop automation, so as to validate the practicality of the NMA architecture and also identify potential areas for future standardization. - Related works
¶ Interop testing/Demo of CoAP-EAP
- Champions
Francisco López Gómez (francisco.lopezg@um.es)
Iván Álvarez Belotto (i.alvarezbelotto@um.es)
Rafael Marín López (rafa@um.es)
Gabriel López Millán (gabilm@um.es) - Project Info
CoAP-EAP was published as RFC 9820 in September 2025. It defines CoAP as a new lower layer for EAP, intended to support authentication in Internet of Things (IoT) and other constrained environments.
Researchers from the University of Murcia (Spain) have developed a new implementation of the final RFC specification to evaluate CoAP-EAP in a representative IoT scenario, including experiments with EAP-EDHOC, a new EAP method currently under standardization. To further validate both the CoAP-EAP implementation and the EAP-EDHOC experiments in constrained networks, this project invites additional implementations to enable interoperability testing.
Additionally, a demo of the current CoAP-EAP implementation in combination with EAP-EDHOC is available in a constrained scenario based on Nordic’s nRF52840-DK and nRF52840 dongle platforms using Thread to communicate, with the aim of promoting discussion on relevant aspects.
Furthermore, RFC 9820 defines the derivation and use of an OSCORE context to protect communication between the EAP Peer and the EAP Server. An alternative version has also been developed in which, instead of using OSCORE, EDHOC-PSK (currently under standardization in the LAKE working group) is executed using the MSK derived from EAP to establish session keys. - Related documents
CoAP-EAP: RFC 9820.
EAP-EDHOC draft: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-edhoc/
EDHOC-PSK draft: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/
¶ Validate YANG-Push to Message Broker End-To-End Data Processing Chain
-
Champion(s)
Thomas Graf (thomas.graf @ swisscom.com)
Leonardo Rodoni (leonardo.rodoni @ swisscom.com)
Ahmed Elhassany (ahmed.elhassany @ swisscom.com)
Benoit Claise (benoit @ everything-ops.net)
Paolo Lucente (paolo @ pmacct.net)
Vivekananda Boudia (vivekananda.boudia @ insa-lyon.fr)
Maxence Younsi (maxence.younsi @ insa-lyon.fr)
Pierre Francois (pierre.francois @ insa-lyon.fr)
Rob Wilton (rwilton @ cisco.com)
Daniel Voyer (davoyer @ cisco.com)
Deepya Mandadi (dmandadi @ blueplanet.com)
Sivakumar Sundaravadivel (sivakuma @ blueplanet.com)
Jérémie Leska (jeremie.leska @ 6wind.com)
Samuel Gauthier (samuel.gauthier @ 6wind.com)
Irfan Mohammad (irfan @ arrcus.com) -
Draft Specifications Message Broker
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-message-broker-telemetry-message
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-anydata-validation -
Draft Specifications YANG-Push
https://datatracker.ietf.org/doc/html/rfc8639
https://datatracker.ietf.org/doc/html/rfc8641
https://datatracker.ietf.org/doc/html/rfc9196
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yp-transport-capabilities
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby -
Project Info
https://www.network-analytics.org/yp/, validate and verify -
5 YANG-Push Publishers
-
2 YANG-Push Receivers
-
2 YANG-Push Network Telemetry Message
-
1 YANG Message Broker Producer and Schema Registry
-
3 YANG Message Broker Consumers
implementation in the area of YANG data schema validation and obtaining latest YANG-Push subscription state. Subscribe to YANG data on YANG-Publisher, obtain and register all YANG modules necessary to build YANG schema tree, register YANG schemas to Schema Registry and verify YANG notifications against scheme trees and produce and consume from Message Broker.
- Repository
https://github.com/network-analytics/ietf-network-analytics-document-status/tree/main/126/Hackathon
https://github.com/NetGauze/NetGauze/releases/tag/v0.12.0
https://github.com/pmacct/pmacct
https://github.com/CESNET/libyang/releases/tag/v5.4.9
¶ Demo of Agent Transfer Protocol (server-mediated messaging for the Internet of Agents)
-
Champions
Xiang Li (lixiang@nankai.edu.cn)
Lu Sun (sunlu25@mail.nankai.edu.cn)
Yuqi Qiu (qiuyuqi@mail.nankai.edu.cn)
Zuyao Xu (xuzuyao@mail.nankai.edu.cn) -
Project Info
The draft <ATP: Agent Transfer Protocol> (https://datatracker.ietf.org/doc/draft-li-atp/) defines the Agent Transfer Protocol (ATP), a server-mediated communication protocol for messaging between autonomous agents across administrative domains. Following the federated, server-mediated model used by SMTP for electronic mail, ATP specifies agent identifier resolution and public-key discovery, a sender authentication mechanism (Agent Transfer Signatures, ATS), recipient-side keying with payload-covering signatures (Agent Transfer Keys, ATK), and a DMARC-style alignment check between ATS and ATK. The error model defines outcomes for cross-domain delivery failures.
This project will produce an interoperability demonstration of ATP, so as to validate the practicality of the protocol architecture and identify potential areas for further standardization. -
Related documents
https://datatracker.ietf.org/doc/draft-li-atp/
¶ Adding PQ capabilities to SSH protocol
-
Champions
Alicja Kario (hkario@redhat.com)
Dmitry Belyavskiy (dbelyavs@redhat.com) -
Project Info
We are interested in providing PQ capabilities to the SSH protocol.
-
We are implementing the draft GSS-API Key Exchange with hybrid ML-KEM (https://datatracker.ietf.org/doc/draft-kario-gss-keyex-pqc/) for OpenSSH (https://github.com/beldmit/openssh-portable/tree/beldmit-f45-103p1-gsshybrids, based on existing patches implementing GSS-API Key Exchange in OpenSSH) and libssh (https://gitlab.com/pzacik/libssh-mirror/-/tree/gssapi-kex-pqc)
-
We are implementing pure ML-DSA signatures (https://datatracker.ietf.org/doc/draft-sfluhrer-ssh-mldsa/) for OpenSSH and libssh.
Docker image with a build: https://github.com/beldmit/openssh-ietf126-hackathon
Also Fedora/Red Hat builds of OpenSSH and libssh upstream supports hybrid ML-KEM/NIST variants using OpenSSL as backend, interoperability with Putty is tested and reached.
¶ Interop testing of new ACME server and client, Akamu
-
Champions
Alexander Bokovoy (abokovoy@redhat.com) -
Project Info
We are interested in testing new ACME server and client, Akamu, which both support PQ capabilities and Merkle Tree Certificates.
We are implementing new ACME infrastructure for FreeIPA and Dogtag PKI projects, https://codeberg.org/freeipa/akamu. It allows to issue certificates in x.509 and Merkle Tree Certificate formats for both classic and PQ cryptography. Akamu also provides MTC cosigner support.
¶ Interop testing of PQC enabled Kerberos PKINIT
-
Champions
Julien Rische (jrische@redhat.com)
Alexander Bokovoy (abokovoy@redhat.com) -
Project Info
We are interested in testing implementation interoperability for post-quantum PKINIT support.
We are working on adding PQC PKINIT support to MIT Kerberos, based on https://datatracker.ietf.org/doc/draft-bokovoy-kitten-pkinit-pqc/
¶ PermitReceipt Reference Evaluation for AI-Agent and Workload External Effects
-
Champions
Yong Bok Lee, Meridian Verity Group, [scott@meridianverity.com] -
Project Info
This project provides a runnable synthetic reference evaluation for PermitReceipt-based permit-before-commit authorization of AI-agent and workload external effects.Related Internet-Draft:
https://datatracker.ietf.org/doc/draft-lee-orprg-permit-receipts/Repository:
https://github.com/meridianverity/permit-receiptPublic evaluation release:
https://github.com/meridianverity/permit-receipt/releases/tag/v2.2.1-public-evalThe evaluation exercises deterministic canonicalization, action-digest binding, policy-epoch checks, scope checks, status and freshness checks, anti-replay handling, and fail-closed denial before a protected external effect is committed.
The project includes a provider-neutral synthetic agentic-commerce profile as one example effect family. It does not process live payments, store payment credentials, call live processors, or provide production payment processing, wallet, issuer, PSP, network-token, or settlement-rail functionality.
Hackathon goals:
- Review whether the PermitReceipt field model is understandable and useful.
- Review canonicalization and action-digest binding behavior.
- Review negative vectors and fail-closed denial behavior.
- Identify missing conformance and interoperability vectors.
- Discuss whether future work should separate requirements, architecture, data model, conformance, and wire-profile documents.
- Collect implementation and reviewer feedback for a future revision of the Internet-Draft.
Expected outputs:
- GitHub issues or pull requests for unclear fields, missing vectors, or implementation gaps.
- Candidate conformance-vector additions for future repository updates.
- Input for a future revision of the Internet-Draft.
Coordination:
- Remote/asynchronous coordination via GitHub Issues and IETF Hackathon communication channels.
- Synchronous review slot to be listed in the Team Schedule.
¶ In-Network Telemetry Aggregation Using IOAM Aggregation Trace and Template Options
-
Champions
Ramon Bister (ramon.bister@ost.ch)
Alexander Clemm (ludwig@clemm.org)
Andrea Mayer (andrea.mayer@uniroma2.it)
Stefano Salsano (stefano.salsano@uniroma2.it) -
Project Info
iOAM (in-situ Operations, Administration, Maintenance) has gained popularity as a mechanism to collect telemetry data from a network. However, what is of interest for many use cases is not so much raw telemetry data records from nodes themselves, but aggregates of telemetry data across the nodes of the path traversed by a packet. For example, aggregating packet dwell times can be indicative of end-to-end latency, identifying the interface with the deepest (maximum) queue depth along a path can expose bottlenecks, aggregating environmental indicators can help assess CO2-intensity of paths to optimize pollution-aware routing.
This hackathon project aims to demonstrate and extend a solution that allows to aggregate inband network telemetry data using new proposed extensions to iOAM for some of the mentioned use cases. The starting point is a PoC that implements the IOAM Aggregation Trace Option as well as the IOAM Template Option with an accompanying template used for telemetry aggregation. The PoC is realized using P4 on BMv2 switches on Ubuntu. In addition, the hackathon project also pursues another option to carry aggregation traces using the concept of a Global Opaque Block (GOB) as an extension to the IOAM Pre-allocated Trace Option. This part of the project will leverage a Linux/eBPF-based PoC implementation. GOB and Template will both share the same common structure/identifier space so that the resulting aggregation trace records (e.g. accumulated dwell time / end-to-end latency) are interchangeable regardless of the option with which they were obtained, as we aim to demonstrate using a single Wireshark dissector.
In summary, our goal is to
- raise awareness and interest in the proposed solution
- compare trace option alternatives
- add support for new use cases, incorporating new aggregations and possibly new instrumentation for data that can be aggregated
- provide a demo for existing and extended use cases
Depending on interest, there are other possibilities that could also be pursued, such as implementing a companion app to actively probe aggregate telemetry and/or to support an intent assurance use case for intent-based networking.
The following are the primary links related to this Hackathon Project:
- Aggregation Trace Option for In-Situ Operations, Administration, and Maintenance (OAM) (https://datatracker.ietf.org/doc/draft-cxx-ippm-ioamaggr/) defines a new option type that allows to aggregate IOAM data along a network path using aggregation functions such as sum, average, minimum, or maximum.
- In Situ Operations, Administration, and Maintenance (IOAM) Template Option (https://datatracker.ietf.org/doc/draft-mbci-ippm-ioam-template-option/) allows to define a fixed-length IOAM Option-Type that can be updated by transit nodes along a path, the contents of which is defined by a template. It is possible to define templates to provide functionality equivalent to the Aggregation Trace Option, which supported as well.
- Global Opaque Block for IOAM PTO: https://datatracker.ietf.org/doc/draft-mayer-ioam-gob/
- Extensible In-band Processing (EIP) Architecture and Framework: https://datatracker.ietf.org/doc/draft-eip-arch/
- Linux/eBPF implementation: https://github.com/netgroup/ioam-gob-kernel-playground
- BMv2/P4 implementation: https://github.com/INSRapperswil/green-path-optimizer
¶ Add Oper State Visibility to IETF-L3VPN-SVC with YANG Push Telemetry
-
Champions
Ian Farrer ian.farrer@telekom.de
Kris Lambrechts kris@intwine.net
Kristian Larsson k@centor.se -
Project Info
The newly formed ONSEN WG is chartered with the creation, extension and maintenance of abstracted service and network YANG modules, such as the L3VPN service model. Currently, this model only includes nodes for configuration of service functionality ('config-true'). The ONSEN WG is chartered to extend the abstracted models to include state data to provide real-time visibility of how a provisioned customer service is currently performing based on collected telemetry, or operational state polling.
The goal of the Hackathon is to extend the existing service configuration functionality of the StratoWeave open-source network orchestration platform to:
- Add telemetry collection via a YANG Push collector
- Implement the necessary intermediate automation logic to aggregate/evaluate collected telemetry
- Create and implement the relevant augmentations to the ietf-l3vpn-svc YANG model to make L3VPN service health visible via RESTCONF at the northbound interface
https://datatracker.ietf.org/doc/draft-wilton-netconf-yang-push-2/
https://datatracker.ietf.org/doc/html/rfc8299
https://github.com/stratoweave
¶ NTP Version 5
-
Champions
Karen O'Donoghue (kodonog@pobox.com)
Dieter Sibold (dsibold.ietf@posteo.com) -
Project Info
Interoperability testing between different NTPv5 implementations. -
Draft Specifications
https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/ -
Repositories
- NTPD-RS: https://github.com/pendulum-project/ntpd-rs
- Experimental: https://github.com/mlichvar/ntp5-exp
- NTPv5 in Chrony: https://github.com/mlichvar/chrony-ntp5
¶ NTS Pool
- Champions
Karen O'Donoghue (kodonog@pobox.com)
Dieter Sibold (dsibold.ietf@posteo.co
David Venhoek (david@venhoek.nl)
Ruben Nijveld (ruben@gewooniets.nl) - Project Info
Creating a pool for NTS servers, using key-exchange servers run by the pool. - Draft Specifications
https://datatracker.ietf.org/doc/draft-venhoek-nts-pool/ - Repositories
- Pool software: https://github.com/pendulum-project/nts-pool
- ntpd-rs with pool support: https://github.com/pendulum-project/ntpd-rs
- chrony with pool support: https://github.com/pendulum-project/chrony
¶ Stream identification for SRv6 PREF
- Champions
Ferenc Fejes ferenc.fejes@ericsson.com - Project Info
IETF DetNet WG defined MPLS dataplane and there is ongoing effort in draft-varga-detnet-srv6-data-plane to define an SRv6 dataplane. The ecnapsulation described in the document implemented in two open-source project:
DNT is a feature-packed, generic software, while XDPPREF focuses on the PREF (and FRER) functionalities only. DNT support wide variety of network headers both for encapsulation and stream identification. XDPPREF only support IPv6 flow-label based stream identification on the edge.
The subject of this project is implementing extended stream identification support for XDPPREF.
In addition to IPv6 flow-label, streams could be identified with other fields of IPv6, or even other network or transport headers.
¶ YANG SID Extensions End-to-End
- Champions
Laurent Toutain (laurent.toutain@imt-atlantique.fr)
Javier A. Fernandez (javier-alejandro.fernandez@imt-atlantique.fr)
Batoul Noureddine (batoul.noureddine@imt-atlantique.fr)
Vojtech Vilimek (vojtech.vilimek@nic.cz) - Project Info
A focused sprint to complete and standardize SID extension support across the YANG SID toolchain. The primary goal is to define a data-model-compliant SID extension format, integrate it into pyang, and specify encoding rules for complex YANG datatypes such as enumerations, bits, and unions. The event will also explore implementation in pycoreconf and registry population workflows. A live demonstration of DNS-based SID discovery will illustrate how SID-extended artifacts can be published, discovered, and consumed in a broader ecosystem.
YANG <--> SID Extension <--> Registry <--> Discovery <--> CORECONF - Draft Specifications
SID Extension to efficiently manipulate YANG Data Models: https://datatracker.ietf.org/doc/draft-toutain-t2t-sid-extension/)
RFC 9595 - YANG Schema Item iDentifier (YANG SID): https://datatracker.ietf.org/doc/rfc9595/) - Repositories
- pyang: https://github.com/core-wg/pyang
- ltn22/pyang: https://github.com/ltn22/pyang
- pycoreconf: https://github.com/alex-fddz/pycoreconf
¶ YANG-Push with COSE Provenance
- Champions
Ana Mendez Perez ana.mendezperez@telefonica.com
Per Andersson per.ietf@ionio.se
Diego Lopez diego.r.lopez@telefonica.com
Robin Osterberg robin.ietf@kodeta.se
Jan Lindblad jan.lindblad+ietf@for.eco
Marisol Palmero mpalmero.ietf@gmail.com - Project Info
The OPSAWG Working Group is developing a YANG Provenance model to provide authenticity, integrity, and traceability for YANG-based telemetry. As networks become increasingly automated and telemetry-driven, operators and controllers need mechanisms to verify that telemetry data originates from trusted sources and has not been modified while traversing the collection pipeline.
This Hackathon project will build an end-to-end prototype using the YANG Provenance model and COSE signatures to demonstrate how telemetry can be signed, verified, and validated from device to collector to consumer applications.
The project will exercise provenance across multiple YANG modules and explore practical deployment considerations, including multiple signatures with COSE countersignatures, multi-stage validation, key distribution, canonical encoding, and streaming telemetry use cases. - Goals for the Hackathon
Connect a simulated device and collector to the Telefónica COSE provenance service.
Demonstrate an end-to-end provenance pipeline: device → YANG-Push → collector → verification service.
Exercise signing and verification using multiple YANG modules, including:
-- ietf-interfaces.yang
-- ietf-bmp.yang
-- IVY data models
-- draft-ietf-green-power-and-energy-yang
- Demonstrate provenance across different telemetry domains, including operational, routing, and power/energy telemetry.
- Investigate canonical representations of YANG JSON, XML, and CBOR data to ensure reliable signature generation and verification.
- Explore COSE countersignatures (RFC 9338), multiple-signature workflows, and multi-stage provenance validation.
- Assess approaches for key distribution and trust establishment between devices, collectors, and validation services.
- Evaluate the feasibility of a lightweight device-side implementation suitable for vendor adoption.
- Signatures will be placed at the YANG-Push notification envelope level, using the second enclosing method defined in the YANG Provenance draft. This approach provides end-to-end integrity from the point of origination through to the consumer, and is the signing boundary recommended for this prototype.
- Draft Specifications
https://www.ietf.org/archive/id/draft-madpr-green-provenance-00.txt - Repositories
¶ SCION Secure Path-Aware Routing
-
Champions
Tony John (tony.john@ovgu.de)
Adrian Perrig (adrian.perrig@inf.ethz.ch)
Lars-Christian Schulz (lars-christian.schulz@ovgu.de)
Tilmann Zäschke (tilmann.zaeschke@inf.ethz.ch) -
Project Info
This project aims to demonstrate interoperability of SCION path-aware routing with all things internet. There are several open-source SCION libraries that facilitate SCION adaptation across various programming languages (Go, Java, C, C++, Rust, Python) and applications. SCION can also interoperate with IPv6 networks via address translation in SCION-IP Translators. All SCION interoperability approaches share a need for robust path selection and packet scheduling as SCION leaves the final routing decision to end host.We are looking for novel project ideas as well as adaptation of existing open-source project to SCION that tackle the challenges and opportunities of end-host-controlled routing, especially as they highlight SCIONs security features. A good starting point for taking advantage of path-aware routing is path metadata (link speed, latency, geographical location, etc.) provided by SCION's control plane and dataplane telemetry provided through In-band Network Telemetry (ID-INT).
-
Hackathon Goals
The aim is to demo and extend existing open-source SCION projects and to spark ideas for new use cases of SCION. We put special focus on how projects deal with the wealth of inter-domain paths that SCION exposes.For example:
-- Demo path selection and in-band telemetry in SCION
-- Offer participants a chance to connect to SCION from their laptops
-- Improve path selection in existing libraries and applications
-- Create new SCION demo applications, e.g.,
-- Create a SCION enabled : curl" CLI tool by adapting Java CURL (https://github.com/rockswang/java-curl) to work with the SCION JPAN library (https://github.com/scionproto-contrib/jpan)
-- Create a demo application that combines SCION with segment routing -
Draft Specification SCION
https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/
https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/
https://datatracker.ietf.org/doc/draft-dekater-scion-pki/ -
Related documentaion etc.
-- List of various SCION libraries and projects: https://github.com/scionproto/awesome-scion
-- SCION documentation: https://docs.scion.org/en/latest/index.html
¶ KIRA – Scalable Zero-Touch Routing
-
Champions
Roland Bless (roland.bless@kit.edu)
Julius Rüberg (julius.rueberg@student.kit.edu) -
Project Info
KIRA is a scalable zero-touch routing architecture that provides IPv6 connectivity without any configuration for hundreds of thousands of nodes. It is ID-based and also works well in fixed networks, data center networks, mobile ad-hoc networks, and LEO satellite networks. The prototypical implementation is written in Rust.
More info at https://s.kit.edu/KIRA
-
Draft Specifications
Internet Draft: https://datatracker.ietf.org/doc/draft-bless-rtgwg-kira/ -
Side Meeting
Thursday, July 23, 2026, 19:00-20:00 ( Europe/Vienna ) · Park Suite 4 -
Hackathon Plan (Potential Working Items)
- Using KIRA as ACP Routing protocol for ANIMA
- Running BRSKI and GRASP based on KIRA's IPv6 connectivity
- Using KIRA together with FRR, bird, etc.:
- KIRA's IPv6 connectivity can be used to configure and set up routing daemon entities
- Use docker containers with kirad together with frr/bird/etc., e.g., for distributed test automation.
- Using KIRA with a mesh of Raspberry Pis
- Using KIRA as ACP Routing protocol for ANIMA
-
Technologies
- Rust (Kirad)
- IPv6
- Linux
- NEST / ContainerNet for testing
- Python for the Web Demo Interface
-
Remote Participation
we will use Gather -
Source Code Repository
- Gitlab Repository: https://gitlab.kit.edu/kit/tm/telematics/kira/kira-rust
- Github Repository is in preparation
¶ CVE-2026-33697 (CVSS 7.5) Intra-handshake.fail
-
Champions
- Muhammad Usama Sardar (muhammad_usama.sardar at tu-dresden.de)
- Viacheslav Dubeyko
- Jean-Marie Jacquet
- Songbo Bu
- Pavel Nikonorov
- (Please feel free to add your name here)
Potential collaboration with project AEP × Veraison: Anton Sokolov
-
Drafts vulnerable to CVE-2026-33697
- Early attestation
- FACTS
- Attestation in (D)TLS -
Project Motivation
- https://www.theregister.com/security/2026/07/04/confidential-computings-trust-mechanism-is-broken-the-fix-may-not-exist/5266056
- https://www.scworld.com/brief/confidential-computings-remote-attestation-protocol-may-have-fundamental-flaw
- https://blogs.groupware.org.uk/01-Quantum-Inc/the-handshake-that-cant-keep-its-promise-why-confidential-computings-flaw-changes-the-data-sovereignty-conversation/
- https://thenextgentechinsider.com/pulse/critical-flaw-discovered-in-confidential-computing-attestation-protocols
- https://www.securitylab.ru/news/574545.php
- Russian https://www.securitylab.ru/news/574545.php
- German https://www.blogspan.net/confidential-computing-attestierung-relay-luecke/
- https://dailysecurityreview.com/resources/cve-2026-33697-attested-tls-relay-flaw-hits-whatsapp-cocos-ai/
- Chinese https://finance.sina.cn/tech/2026-07-04/detail-inifscxt9953361.d.html
- https://data4biz.com/articles/una-falla-rompe-la-fiducia-del-confidential-computing
- Japanese https://blackhatnews.tokyo/archives/119915
- https://www.dugganusa.com/post/confidential-computing-s-whole-pitch-is-trust-the-proof-not-the-cloud-two-years-of-formal-verifi
- https://post.smzdm.com/p/a82ol990/
- Russian https://www.itsec.ru/news/issledovateli-nashli-kriticheskuyu-uyazvimost-v-attested-tls
- Chinese https://blog.csdn.net/weixin_42376192/category_13096766.html
- https://daily.dev/posts/bad-epoll-hits-99-reliability-sharepoint-rce-under-active-exploitation-zgp0yt8lh
- https://meterpreter.org/attested-tls-vulnerability-cve-2026-33697/
- https://osintsights.com/confidential-computing-flaws-expose-trust-risks
- https://www.boerse-express.com/news/articles/digitale-souveraenitaet-vergabebeschleunigungsgesetz-staerkt-europaeische-cloud-ab-juli-924836
- Turkish: https://hardwaremania.com/haber/arastirma-attested-tls-confidential-computing-icin-zayif-kaliyor/
- https://akber.com/sovereignty-in-the-cloud-is-an-illusion/
- https://www.itsec.ru/news/issledovateli-nashli-kriticheskuyu-uyazvimost-v-attested-tls
- German https://www.ad-hoc-news.de/wissenschaft/digitale-souveraenitaet-bundesregierung-beschliesst-34-punkte-paket/69692503
-
Implementations vulnerable to CVE-2026-33697
- Meta’s Private Processing for WhatsApp
- Cocos AI
- Confidential Computing Consortium (CCC) Attestation SIG's adopted project -
Project Background
Code under Apache-2.0 License: https://github.com/CCC-Attestation/formal-spec-KBS
Paper: https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS -
Project Info
- 3 fundamental ways to combine attestation in TLS:
- Pre-handshake attestation
- Intra-handshake attestation
- Post-handshake attestation
- Internet draft
- Sec. 4 in this paper
- Complicated Hybrids (Intra-handshake attestation + Post-handshake attestation)
- 3 fundamental ways to combine attestation in TLS:
-
Hackathon plan
- Discuss the nits of relay attacks
- Discuss possible solutions
- Discuss open issues
- What is the "long-term identity" of the CC workload? How is "long-term identity" assigned to the CC workload? Which entity supplies this "long-term identity"? How is that Identity Supplier trusted?
- How is CA-certified Long-Term Key (LTK) injected in the Confidential Computing workload in the first place?
- Formal evaluation of new proposals in SEAT
- We aim to seek collaborators (knowledgeable about at least one of the following: TLS, remote attestation, formal methods or confidential computing) who will join us in this project. We also welcome reviewers who can give us feedback on the draft. If you are interested, please contact by email.
- Tool for formal analysis: We currently use ProVerif but other tools are very welcome.
-
Background on Attestation
-
Background on Diversion Attacks
-
Background on Relay Attacks (CVE-2026-33697)
¶ AEP × Veraison: conformant RATS appraisal of AI-agent action evidence, and a reference-scheme freshness fix
-
Champions
Anton Sokolov (Tyche Institute, Tallinn) anton.sokolov@tyche.institute -
Project Info
This project carries an application-layer Action Evidence Package (AEP) — a signed, append-only record of what an (AI) agent did, who authorised it, and the outcome — end-to-end through a conformant Project Veraison RATS Verifier, and closes a freshness gap found in Veraison's referencetpm-enacttrustscheme. The pattern treats the AEP as application-layer Evidence (RATS, RFC 9334) and output-binds it to a hardware-rooted TPM quote: the AEP outcome digest rides inside the signed quote, so the agent — which is both witness and suspect over its own log — cannot swap the outcome without breaking the signature. -
What runs today (emulated swtpm)
A real Project Veraison verifier appraises a Tyche AEP-boundswtpmquote (CoRIM provisioning → challenge-response → signed EAR), returningaffirmingfor good evidence andcontraindicatedfor an outcome-swap or signature tamper. This validates the composition/conveyance mechanics against an emulated software TPM — an interoperability result, not a hardware guarantee and not a Veraison endorsement. It also surfaced that the referencetpm-enacttrustscheme checks the signature and PCR digest but not challenge-nonce freshness, so a replayed quote still appraisesaffirming(filed asveraison/services#427). -
New since listing — a MachineMandate in the real EU wallet. We issued a MachineMandate (a machine-readable delegation: principal, allowed action, spend limit, action hash) as an SD-JWT VC into the actual EU reference wallet over OpenID4VCI, and present it over OpenID4VP to the EC reference verifier (trusted-list-backed). A payment agent runs it live: a €250 invoice is accepted; a €5,000 payment is denied for exceeding the delegated limit; a prompt-injected "wire it elsewhere" is denied because that tool and payee were never in the mandate. On a real phone, on a single tap, the wallet presents the mandate and the verifier accepts it. (Software TPM in the PoC.)
-
Composition — the four-box chain. PermitReceipt (Y. B. Lee) authorises before commit → the MachineMandate is the authority the action is checked against → the SCITT Agent Action Capsule (S. Mih,
draft-mih-scitt-agent-action-capsule) records what happened → AEP/RATS attests the platform. The AAC × AEP cross-verification is closed both ways — one capsule_id, one response_digest, two independent trust roots. -
Hackathon goals
- Re-run the pipeline on a real hardware TPM (
/dev/tpmrm0), live beside the Veraison maintainers, to retire the "emulated-only" caveat. - Finish the two-part freshness fix: (1) a scheme patch surfacing the attester-bound nonce as a claim; (2) a Rego policy comparing it to the session nonce — show the measured
affirming→contraindicatedflip on a replayed quote. - Interop: invite other RATS / TPM implementers to appraise an AEP-bound quote; compare verdict mappings (AR4SI / EAR).
- Re-run the pipeline on a real hardware TPM (
-
Standards context (Internet-Drafts unless marked RFC)
- This work: draft-sokolov-rats-aep-composition — individual submission, not WG-adopted
- RFC 9334 RATS Architecture · RFC 9711 Entity Attestation Token (EAT)
- draft-ietf-rats-ar4si (AR4SI) · draft-ietf-rats-ear (EAR) · draft-ietf-rats-msg-wrap (CMW) · draft-ietf-rats-corim (CoRIM) · draft-ietf-rats-multi-verifier
-
Repositories & artifacts
- Project Veraison: https://github.com/veraison/services — freshness issue: https://github.com/veraison/services/issues/427
- Reference implementation (EATF / AEP): https://github.com/tyche-institute/eatf
- Preprint (method, decoded EARs, freshness policy): https://doi.org/10.5281/zenodo.20818672
-
Related Hackathon projects (collaboration welcome)
- PermitReceipt (Y. B. Lee) — permission before the effect: draft-lee-orprg-permit-receipts. Their permit-before + our proven-outcome-after = one accountability chain.
- Intra-handshake.fail (M. U. Sardar) — attested TLS / formal methods: draft-usama-seat-intra-vs-post.
- SCITT Agent Action Capsule (S. Mih) — content-private COSE_Sign1 agent-action record anchored in SCITT; the record box of the four-box chain: draft-mih-scitt-agent-action-capsule
-
Coordination
Onsite in Vienna — champion attends in person (first IETF / first Hackathon). Remote collaborators from RATS / TPM / Veraison very welcome; sync slot to be listed on the Team Schedule.
¶ Security for Agent Communication
-
Champions
Jiang Yuning (jiangyuning2@h-partners.com)
Song Yurong (songyurong1@huawei.com)
Foo Chuan Ann (foo.chuan.ann1@h-partners.com)
Tu Yaowei (tuyaowei@h-partners.com) -
Project Info
In recent years, AI agents have witnessed remarkable progress and are increasingly recognized as a pivotal force in various fields. However, as these agents interact with one another, external tools, and data sources, the security of their communication channels has become a critical concern. Ensuring secure and trusted interactions is no longer optional but essential for maintaining system integrity and data confidentiality.
We are continuously working to implement and test Agent Protocol Security in IETF#123 and #125. Now we are expanding the scope from the security for agent protocol to the broader agent communication layer. In this Hackathon, we are planning to test security tools and agent skills focused on three key areas: intent source validation, agent and tool identity, and heterogeneous credentials verification. -
Agent Protocol Background
https://modelcontextprotocol.io/
https://www.a2aprotocol.org/ -
Related Drafts
https://www.ietf.org/archive/id/draft-jiang-intent-security-03.html
https://www.ietf.org/archive/id/draft-jiang-wimse-heterogeneous-credential-00.html
https://www.ietf.org/archive/id/draft-song-oauth-ai-agent-collaborate-authz-01.html
https://www.ietf.org/archive/id/draft-jiang-oauth-intent-admission-00.html -
Repositories
https://agent-security-labs.github.io/agentic-security-hackathon-plan/agentic-security-hackathon-plan.html
¶ Heterogeneous Credential Verification for Workload and Agentic Systems
-
Champions
Jiang Yuning (jiangyuning2@h-partners.com)
Song Yurong (songyurong1@huawei.com)
Foo Chuan Ann (foo.chuan.ann1@h-partners.com)
Tu Yaowei (tuyaowei@h-partners.com) -
Project Info
Workload and agentic systems may receive multiple credentials in one request, such as workload identity credentials, OAuth access tokens, JWTs, X.509 certificates, verifiable credentials, API keys, and opaque tokens. These credentials can use different formats, issuers, and verifiers, while the receiver still needs to make one handling decision for the request.This project will test a heterogeneous credential verification pipeline for workload and agent communication. The prototype receives a mixed credential set, identifies each credential type, routes credentials to the appropriate verifier, normalizes verification results, and applies a decision policy.
-
Hackathon Plan
We plan to test the following items:- Receive one request carrying multiple credential types.
- Identify credential types and select the corresponding verifiers.
- Normalize verifier outputs into a common result model.
- Apply a decision policy and show different outcomes through demo scenarios.
-
Related Drafts
https://datatracker.ietf.org/doc/draft-jiang-wimse-heterogeneous-credential/01/ -
Repositories
https://github.com/agent-security-labs/wimse-heterogeneous-credential-draft
¶ RPKI-based Validation with Prioritized Resource Data
-
Champions
Jia Zhang (zhangj@zgclab.edu.cn)
Mingwei Xu (xmw@cernet.edu.cn)
Nan Geng (gengnan@huawei.com)
Chongfeng Xie (xiechf@chinatelecom.cn)
Yangyang Wang (wangyy@cernet.edu.cn) -
Project Info
This project explores priority-safe use of local or supplemental routing-security data together with signed RPKI data. Operators may use ROAs, SLURM entries, IRR-derived inputs, local exceptions, customer records, or other local data in validation and filtering workflows, but these inputs may have different authority or assurance levels. We will prototype practical deployment models, especially multi-cache / multi-table validation using existing RTR/cache/router mechanisms, so that signed RPKI semantics are preserved while operators can apply local actions such as reject, deprefer, warn, monitor, or exception handling. -
Hackathon Plan
We will build a Proof of Concept (PoC) to demonstrate the multi-priority RPKI Route Origin Validation (ROV) framework. Our development will focus on two core tasks:- RTR Protocol Extension: Modify the RPKI-to-Router (RTR) protocol to allow Protocol Data Units (PDUs) to explicitly carry priority levels for validated RPKI payloads from the cache server to the router.
- Priority-Aware ROV: Parse RTR priority attributes to support multi-priority validation states and enable differentiated BGP routing policies (e.g., discard vs. lower Local Preference).
-
Related Drafts
https://datatracker.ietf.org/doc/draft-zhang-sidrops-prioritized-route-validation/
¶ ASPA-based AS_PATH Verification for BGP Export
- Champions
Jia Zhang (zhangj@mail.zgclab.edu.cn)
Yangyang Wang (wangyy@cernet.edu.cn)
Maria Matejka (maria.matejka@nic.cz)
Mingwei Xu (xmw@cernet.edu.cn)
Kotikalapudi Sriram (ksriram@nist.gov)
Nan Geng (gengnan@huawei.com)
- Project Info
This project explores practical deployment of ASPA-based AS_PATH verification at eBGP egress. ASPA verification is primarily defined for validating received BGP routes, but operators may also benefit from checking routes before they are exported to external neighbors. Egress-side verification can help detect export-policy mistakes, AS_PATH manipulation errors, AS migration or renumbering issues, missing provider ASPA records, and partial deployment gaps inside an AS.
The project will prototype how egress ASPA verification can be implemented in routers, route servers, or detached monitoring systems. The work will focus on how an egress verifier determines the relevant AS_PATH, local AS, neighbor AS, BGP Role or local relationship, OTC or equivalent leak-prevention signal, and export-policy context before deciding whether a route should be propagated, warned, monitored, or blocked.
The goal is to preserve the semantics of the base ASPA verification procedures while exploring operational models for export-side assurance and route-leak prevention.
- Hackathon Plan
We will build a Proof of Concept (PoC) to demonstrate ASPA-based AS_PATH verification at eBGP egress. Our development will focus on three core tasks:
-
Basic Egress ASPA Verification
Implement a prototype that performs ASPA-based AS_PATH verification on routes before they are exported to eBGP neighbors. The prototype will construct the AS_PATH as it would be seen at egress, apply the appropriate ASPA upstream or downstream verification procedure according to the neighbor relationship, and identify routes that would become ASPA Invalid after export.
-
Neighbor-AS and Export-Context Handling
Explore how the verifier obtains and uses egress-specific context, including the egress ASBR, local AS, neighbor AS, BGP Role or locally configured relationship, OTC or equivalent intra-AS leak-prevention signal, and export-policy information. The prototype may also evaluate Neighbor-AS-Augmented Verification as an optional mode for operational assurance or deployment-specific checking.
-
Deployment and Policy Modes
Demonstrate different deployment modes, including inline egress enforcement, alert-only operation, detached/offline verification, and centralized or Route Reflector assisted monitoring. The prototype will map verification outcomes to local actions such as
SHOULD NOT propagate, warning, logging, monitoring, or local policy-driven handling.
- Related Drafts
https://datatracker.ietf.org/doc/draft-zhang-sidrops-aspa-egress/
¶ Cat Privacy: Testing Ciphertext AI inference in the MCP tool
-
Champions
Lun Li (lilun20@huawei.com)
Yaowei Tu (architect117@u.nus.edu) -
Project Info
The academic community has been proposing new privacy technologies, but in existing networks, more pseudonymization is used to protect identifiers. Can these new privacy technologies enhance processing privacy?In this project, we try to let the network perform computing directly on ciphertext through privacy computing. The potential solution is to use homomorphic encryption. AI inference and neural networks are the types of computation we are primarily coped with. The main goal is as follows: -
Hackathon Plan
-
Test the performance of homomorphic encryption in AI inference
-
Finish a MCP tool using FHE to complete ciphertext AI inference
-
Try your own cats( or dogs if you like) in the LLM to perform the ciphertext AI inference in the MCP tool.
-
Related Drafts
https://datatracker.ietf.org/doc/draft-li-pearg-ciphertext-inference-tool-mcp/
¶ ICON: AI Agent observability for network management operations
-
Champions
Qin Wu (bill.wu@huawei.com)
Qiufang Ma (maqiufang1@huawei.com)
Luis M. Contreras (luismiguel.contrerasmurillo@telefonica.com)
Wei Song (songwei80@huawei.com)
Junjie Luo (luojunjie6@huawei.com)
Mingyuan Chen (chenmingyuan3@huawei.com)
Yanping Cao (caoyanping@huawei.com) -
Project info
Our aim is to develop an AI agent observability framework for network diagnosis AI agent to capture its internal reasoning process (Chain-of-Thought), decision-making logic, workflow execution, and operational metrics. This framework could serve as the foundational prerequisite for enabling advanced capabilities, such as agent control and run-time intervention, and AI agent benchmarking. -
Related Drafts
https://datatracker.ietf.org/doc/draft-wnd-opsawg-icon-ps/
https://datatracker.ietf.org/doc/draft-mcw-opsawg-icon-requirements/
https://datatracker.ietf.org/doc/draft-contreras-bmwg-ai-agent-benchmarking/
¶ Security Evaluation Benchmark for AI Agents
-
Champions
Meiling Chen (chenmeiling@chinamobile.com)
Yu Han(hanyu@chinamobile.com) -
Project Info
This project provides a security evaluation benchmark for AI agents, evaluating dimensions like algorithms, data, execution, third-party components, and evolution. Key metrics include adversarial, privacy, and jailbreak defenses, as well as plugin, skill and autonomous iteration security. Using static and dynamic testing, the framework assesses agents before, during, and after deployment. By scoring these metrics, it quantitatively evaluates the security posture, enabling direct capability comparisons and security grading across agents. The main goal is as follows: -
Hackathon Plan
-
Carry out the evaluation demonstration of two ai agents based on the evaluation benchmark.
-
Related Drafts
- Security Evaluation Benchmark for AI Agents: https://www.ietf.org/archive/id/draft-han-bmwg-agent-security-benchmark-00.html
¶ Low-Latency, Low-Loss, Scalable Throughput (L4S) and Accurate ECN Interop
- Champions
Greg White (g.white@cablelabs.com) - Project Info
L4S and AccECN enable applications to receive fine-grained congestion feedback from the network that allows them to achieve full link utilization, ultra-low latency, ultra-low latency variation, and near-zero packet loss.
This Interop Event will bring together different congestion control implementations and different network implementations of L4S, TCP Accurate ECN, QUIC AckECN, WebRTC, etc. to test RFC/draft compliance, interoperability, and performance in various conditions. - Related RFCs
RFC9330
RFC9331
RFC9332
RFC9768
RFC8888
¶ DNS-AID: AI Agent Discovery via DNS
-
Champions
- Jim Mozley (jmozley@infoblox.com)
- Igor Racic (iracic@infoblox.com)
- Nic Williams (nwilliams@infoblox.com)
- Daniel King (d.king@lancaster.ac.uk)
-
Project Info
DNS for AI Discovery (DNS-AID) explores how AI agents and agentic workloads
can publish and discover connectivity and capability metadata using existing
DNS mechanisms, including SVCB, DNS-SD-style names, DNSSEC, and optional
DANE/TLSA. -
Hackathon Plan
The scneario is based on a threat-intelligence federation use case. An AI SOC analyst
assistant needs anip-reputationcapability that was not pre-wired into
the assistant. The assistant uses DNS-AID to discover how to find and invoke
the published capability. DNS-AID publication provides discovery and
invocation metadata; the actual IP reputation verdict is produced only after
the discovered MCP tool is invoked.- Demonstrate DNS-AID publication and discovery of an agent or capability.
- Exercise DNSSEC validation of DNS-published discovery metadata.
- Show how DNS-AID records can point to richer capability and policy
documents. - Demonstrate a client flow from discovery to invocation of a remote MCP
tool. - Validate record formats and discovery flows against the current draft.
- Test capability-document retrieval and integrity checks.
- Identify implementation issues around SVCB parameters, TXT fallback,
DNSSEC, capability document signing, and gateway integration. - Explore the boundary between discovery metadata, capability description,
runtime invocation, and trust in the discovered agent. - Document gaps, interoperability questions, and proposed draft
clarifications.
-
Related Documents
- DAWN Requirements: https://datatracker.ietf.org/doc/draft-king-dawn-requirements/
- DNS-AID draft: https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/
- DAWN Proposed Charter: https://github.com/danielkinguk/discovery/blob/main/charter/
¶ cBRSKI IoT device onboarding protocol (interop)
-
Champions
Esko Dijk (esko.dijk@iotconsultancy.nl) -
Project Info
cBRSKI is an onboarding protocol for IoT devices to automatically and securely onboard a new network domain. It uses EST-coaps for enrollment into the domain. This project will work on cBRSKI implementation for 6LoWPAN mesh nodes (specifically, implementing Thread) and the required back-end infrastructure. We'll also attempt some interop testing if sufficient implementations are available for that. -
More Info
See the hackathon Thread project page, item 'cBRSKI' for more info.
¶ Agent-Awareness in IPv6 Networks: Problem Statement and Framework
- Champions
Huang Tianyi (tyhuang@cnic.cn)
Pang Ran (pangran@chinaunicom.cn)
Han Mengyao (hanmy12@chinaunicom.cn)
Zhao Jing (zhaoj501@chinaunicom.cn)
Han Zhengxin (hanzx21@chinaunicom.cn) - Project Info
The Internet of Agents (IoA) raises a question beyond IPv6 address space and end-to-end connectivity: should an IPv6 network be able to relate packet forwarding to agent capability, policy, and short-lived execution state? This informational document states the problem, sketches a framework for agent-aware IPv6 forwarding, and lists open questions for community discussion. It does not define packet formats, routing extensions, IANA allocations, or a new agent discovery protocol. - Related Documents
¶ Applying YANG Provenance Countersignatures in Kafka workflows
- Champions
Diego López, diego.r.lopez@telefonica.com
Ana Méndez, ana.mendezperez@telefonica.com
Lucia Cabanillas, lucia.cabanillasrodriguez@telefonica.com - Project Info
At previous IETF Hackathons (IETF 122–125), we introduced and evolved a YANG provenance signature framework, based on COSE, to ensure origin authenticity and integrity of YANG data elements. The framework has been progressively integrated with Kafka-based data infrastructures and aligned with ongoing standardization efforts.
For the IETF 126 Hackathon, we extend this work by introducing a Kafka-based workflow leveraging COSE countersignatures, enabling multi-actor attestation and chained trust across distributed processing pipelines.
In modern data pipelines, especially those based on event streaming (e.g., Kafka), multiple entities interact with data objects at different stages (associated to different devices or functions). While basic signatures ensure origin integrity, they do not capture intermediate processing steps or delegated trust assertions.
To address this, we implement a countersignature-based provenance model, where each processing step can attach cryptographic evidence without breaking or replacing prior signatures. - Related Documents
- Related Repositories
¶ Sketch-Based Network State Exchange for Agent-Assisted Network Operations
-
Champions
Mingzhe Xing (xingmz@zgclab.edu.cn)
Linzhe Li (lilz@zgclab.edu.cn)
Yujia Gao (gaoyj@zgclab.edu.cn) -
Project Info
Agent-assisted network operations increasingly depend on timely and trustworthy operational state. However, sending raw telemetry, flow records, device counters, or configuration data to every agent or analysis component can be expensive, slow, and difficult to share across administrative boundaries. Raw state may also contain sensitive customer, topology, or traffic details that should not be disclosed when an aggregate answer is sufficient.
This Hackathon project explores a minimal implementation of compact network state exchange based on Sketch data structures. The initial demo focuses on DDoS evidence exchange: two simulated domains convert IPFIX-like flow records into Count-Min Sketch state artifacts, exchange and merge those artifacts, and provide an agent-facing heavy-hitter report. The report includes query scope, provenance, freshness, bounded-error metadata, privacy caveats, audit identifiers, and a clear statement that the artifact is evidence only and does not authorize automatic mitigation. -
Related Drafts
https://xmzzyo.github.io/nmop-agent-sketch-com/draft-cui-nmop-agent-sketch-com.html
https://datatracker.ietf.org/doc/draft-cui-nmop-agent-sketch-com
¶ Testing Congestion Control and Queue Management Mechanisms
-
Champions
Mohit P. Tahiliani (tahiliani@nitk.edu.in)
Abhyuday K. Hegde (akh.241cs201@nitk.edu.in)
Vishal Kamath (vishalkamath.221cs261@nitk.edu.in) [Remote] -
Project Info
Objective 1: Performance Evaluation of FQ-CoDel and FQ-PIE in Mobile Hot Spot (MHS)
Objective 2: Testing the integration of picoquic with ns-3
Objective 3: Developing a NeST based Congestion Control Evaluation Suite compliant with RFC 9743
Objective 4: Develop an example to demonstrate the implementation of rate-limited sender in ns-3 -
Related Documents
-
Related Repositories
¶ AI-Assisted Network Fault Localization and Issue Discovery System
- Champions
Zhao Jing (zhaoj501@chinaunicom.cn)
Pang Ran (pangran@chinaunicom.cn)
Han Mengyao (hanmy12@chinaunicom.cn)
Han Zhengxin (hanzx21@chinaunicom.cn)
Huang Tianyi (tyhuang@cnic.cn) - Project Info
This project demonstrates an AI-assisted system for network fault localization and issue discovery. It correlates symptoms, telemetry, topology, configuration, logs, and alarms to identify probable fault locations, root causes, supporting evidence, and remediation suggestions. - Related Documents
¶ ACME-RATS Open Source Implementation Status Update (Client-side)
-
Champions
Peter Liu (liuchunchi@huawei.com) -
Project Info
This document (ACME-RATS) describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). -
Related documents
draft-ietf-acme-rats-01
¶ OpenNHP: Network-infrastructure Hiding Protocol (NHP)
-
Champions
Benfeng Chen
benfeng@gmail.com(Additional contributors and collaborators are welcome during the hackathon.)
-
Project Info
OpenNHP is an open-source implementation of the Network-infrastructure Hiding Protocol (NHP), an emerging Zero Trust protocol that provides authenticate-before-connect semantics through cryptographic authentication and network resource hiding.
Unlike traditional security approaches that protect visible services, NHP aims to prevent reconnaissance, DDoS attacks, and pre-authentication exploits by making protected network resources invisible to unauthorized entities. NHP extends concepts from Software-Defined Perimeter (SDP) and Single Packet Authorization (SPA) using modern cryptographic techniques including mutual authentication, continuous verification, and resource obfuscation.
For the IETF 126 Hackathon, we invite participants to actively evaluate, test, and attempt to bypass the security properties of OpenNHP.
-
Challenge objectives include:
- Discovering protected services without authentication
- Performing network reconnaissance against NHP-protected infrastructure
- Enumerating hidden ports, IP addresses, and domain names
- Bypassing authentication or authorization mechanisms
- Testing resistance against DDoS and pre-authentication attacks
- Identifying protocol design or implementation weaknesses
- Evaluating cryptographic assumptions and security properties
- Experimenting with AI-assisted attack techniques
- Performing interoperability and performance testing
-
Success criteria:
- If participants can discover or access protected resources without successful authentication, we want to understand and fix the weakness.
- If participants cannot bypass the invisibility mechanisms, the exercise provides additional confidence in the security properties of the protocol.
We believe that open adversarial testing, public peer review, and running code are essential for building trustworthy Internet security protocols.
-
Links:
-
Website: https://opennhp.org/
-
Source Code: https://github.com/OpenNHP/opennhp
-
Live Demo: https://opennhp.org/demo/
-
Internet-Draft: https://datatracker.ietf.org/doc/html/draft-opennhp-ztcpp-nhp
-
¶ LTV-JWS: Long-Term Validation for JSON Web Signature
Champion: Naoto Miyachi
Internet-Draft:
https://datatracker.ietf.org/doc/draft-miyachi-ltv-jws/
Source code:
https://github.com/miyachi/draft-miyachi-ltv-jws/tree/main/implementation
LTV-JWS is an extension of JSON Web Signature (JWS) for lightweight
long-term validation. It defines signature levels including SIG-B and
SIG-T, RFC 3161 timestamps, validation information, archive timestamps,
and external references.
An experimental Java reference verifier is available in the repository.
It currently supports JWS signature verification, SIG-B and SIG-T,
RFC 3161 timestamp verification, certificate-path validation using local
trust anchors, CRL-based certificate-status checking, and verification of
referenced JWS files.
¶ Hackathon goals
- Clone and run the reference verifier on Windows and Linux.
- Verify the included SIG-B, SIG-T, and referenced-JWS examples.
- Create and verify independently generated LTV-JWS test vectors.
- Test interoperability of JWS signatures, RFC 3161 timestamps, external
references, and CRL-based certificate-status checking. - Identify specification ambiguities, interoperability issues, and useful
additions to the reference implementation. - Record findings as GitHub Issues or proposed Internet-Draft changes.
¶ Suggested tasks
- Prepare independent SIG-B and SIG-T test objects.
- Test verification with certificates and timestamp tokens from a different
implementation or service. - Review handling of protected and unprotected LTV-JWS header objects.
- Review
refsintegrity verification and referenced JWS processing. - Test online CRL retrieval and
-offlineverification behavior. - Improve test vectors, documentation, or build instructions.
¶ Skills useful for participants
Java, JOSE/JWS, PKI, X.509 certificates, RFC 3161 timestamps, CRLs,
JSON processing, and interoperability testing.
¶ Notes
This is an experimental reference implementation intended for
interoperability discussion and demonstration. It is not production
software.
The verifier currently supports CRL retrieval for online certificate-status
checking. OCSP is not currently supported.
This is the champion's first IETF Hackathon.
Newcomers and experienced participants alike are welcome.
¶ Team coordination
Please contact Naoto Miyachi after the Hackathon team-formation session.
The meeting location will be announced on this page at the event.
Participants are welcome to join at any time during the Hackathon.
Contact:
- In person: Naoto Miyachi
- Online: GitHub Issues in the project repository
- Email: miyachi@langedge.jp
Participants are encouraged to clone the repository and run the included
examples before joining, but this is not required.
¶ PQC DNSSEC MTL Mode Additional Benefits
-
Champions
Joe Harvey (jsharvey@verisign.com)
Swapneel Sheth (ssheth@verisign.com)
Andrew Kaizer (akaizer@verisign.com) -
Draft Specifications
[1] https://datatracker.ietf.org/doc/draft-harvey-cfrg-mtl-mode/
[2] https://datatracker.ietf.org/doc/draft-harvey-cfrg-mtl-mode-considerations/
[3] https://datatracker.ietf.org/doc/draft-fregly-dnsop-slh-dsa-mtl-dnssec/ -
Project Info
This hackathon topic continues our evaluation of post-quantum cryptography (PQC) DNSSEC with MTL Mode by focusing on the benefits of MTL Mode beyond support for smaller signatures over the wire. MTL Mode can help with things like signing and verification performance, in particular for slower PQC signature algorithms, and reducing cache sizes in resolvers. -
Related Groups
• PQ DNSSEC Research Side Meetings
• DNS Operations (DNSOP) Working Group
• Crypto Forum Research Group (CFRG)
• Post-Quantum Use in Protocols (PQUIP)
¶ Advancing unicoap in RIOT OS
unicoap is the unified and modular CoAP stack in RIOT OS, the friendly operating system for the IoT
- Champions
- Project Info
Integrating advanced CoAP features into RIOT, PRs (Block-wise transfer, Observation), Multicast, OSCORE
¶ IPsec / IKEv2 interop and performance testing
-
Champions
Paul Wouters
Steffen Klassert -
Project Info
Continued interop of IKEv2 drafts such as draft-ietf-ipsecme-ikev2-mlkem, draft-ietf-ipsecme-child-pfs-info, draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt and IPsec performance testing for per-CPU Child SA's (RFC 9611), IPTFS (RFC 9347) and maybe some EESP draft-ietf-ipsecme-eesp hacking.
¶ Rocca-S for high throughput communication
- Champions
Yuto Nakano (yt-nakano@kddi.com) - Project Info
Rocca-S is an authenticated encryption with associated data (AEAD) algorithm designed for high-performance applications.
This project aims to evaluate the throughput of encrypted communication in a 100GbE environment and investigate the impact of different encryption algorithms on throughput. In particular, we will compare the throughput achieved by AES-256-GCM against that of Rocca-S. - Related draft
Encryption algorithm Rocca-S
https://datatracker.ietf.org/doc/draft-nakano-rocca-s/
¶ Implementing PSK Support and embedded-cal Integration in Lakers
-
Champions
William Takeshi Pereira (william.a.pereira@inria.fr) -
Project Info
Lakers is a Rust implementation of EDHOC (Ephemeral Diffie-Hellman Over COSE). This project aims to extend Lakers with support for the PSK (Pre-Shared Key) authentication method, enabling EDHOC to be used in scenarios where devices share a pre-established secret rather than relying on public-key credentials, which is particularly useful for constrained devices with limited resources for asymmetric cryptography.
In addition, this project will integrate embedded-cal into Lakers, providing a common cryptographic accelerator abstraction layer (CAL) interface for embedded targets. This will allow Lakers to more easily leverage hardware-accelerated cryptographic operations across different embedded platforms, improving performance and portability in constrained device deployments. -
Related documents
EDHOC: RFC9528
Lakers: https://github.com/lake-rs/lakers
embedded-cal: https://github.com/lake-rs/embedded-cal/
¶ Model for distributed authorization policy sharing
-
Champions
Lucia Cabanillas, lucia.cabanillasrodriguez@telefonica.com
Diego López, diego.r.lopez@telefonica.com
Ana Méndez, ana.mendezperez@telefonica.com
Pedro Martínez-Julia, pedromj@gmail.com -
Project Info
This project demonstrates a framework for sharing and managing authorization policies using a YANG-based model.
Authorization policies are expressed using declarative Policy-as-Code languages (e.g., Rego) and encapsulated in a YANG artifact that includes metadata such as owner, author, origin, area, and language.
The prototype implements a policy lifecycle workflow in which a Policy Administration Point (PAP) validates a policy artifact and routes it, based on its area, to the corresponding Policy Decision Point (PDP).
The demonstration shows how a YANG-based policy artifact can be created, validated, distributed, and enforced across two independent domains, with support for updates, deletion, and rollback to previous versions. -
Related Drafts
https://datatracker.ietf.org/doc/draft-cabanillas-nmop-authz-policy-sharing-model/03/ -
Related Repositories
https://github.com/LuciaCabanillasRodriguez/authz-policy-sharing-model
¶ GROWing BGP Terms & Security Documents
-
Champions
Tobias Fiebig (tobias@internet.wien) -
Project Info
The idea for this group is doing a 'polishing run' on two currently active drafts dealing with BGP security and global routing operations terminology currently in use. Both need ample polishing to 'get there', but still should be polishable in the time a hackathon allows. -
Related Drafts
https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-sec-inform/
https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/
¶ Happy Eyeballs Webtester
- Champions
Tim Betzer (tim.betzer@tum.de)
Marcel Kempf (marcel.kempf@tum.de)
Johannes Zirngibl (jzirngib@mpi-inf.mpg.de) - Project Info
The Happy Eyeballs algorithm improves connection establishment by reducing delays when multiple network paths or address families are available. The current Happy Eyeballs v3 draft refines previous versions with updated connection racing behavior and implementation guidance.
This Hackathon project focuses on the Happy Eyeballs WebTester, a web-based platform for testing and visualizing Happy Eyeballs behavior and evaluating implementations against the draft.
During the Hackathon we plan to continue development of the WebTester, discuss and implement new test scenarios, and explore additional ideas around Happy Eyeballs v3. Participants are welcome to contribute new scenarios, implementation experience, interoperability testing or just talk about the draft.
A staging environment with experimental features, new test cases and the code will be available for participants throughout the event. - Related Draft
https://datatracker.ietf.org/doc/draft-ietf-happy-happyeyeballs-v3/ - Links
https://www.happy-eyeballs.net/
https://github.com/happy-eyeballs/he-webtester
¶ Issues and Incidents Identification using Agentic AI and Knowledge Graph
-
Champions
Henry Yu (hyu2010b@gmail.com) -
Project Info
This project demonstrates how incidents [1] and issues [2] can be identified and reported in optical networks using agentic AI and knowledge graphs.
-- AI agents are used to identify, locate, analyze, and report issues and incidents. Throughout this process, the agents employ cognitive reasoning to correlate information and infer root causes.
-- Knowledge graphs are constructed from multiple network data sources, including TE topology, services, inventory, and alarms. They provide a unified ontology to assist the reasoning performed by the Agents.
-- The issues and incidents are reported using their YANG models. -
Links
[1] https://datatracker.ietf.org/doc/draft-ietf-nmop-network-incident-yang/
[2] https://datatracker.ietf.org/doc/draft-yu-ccamp-sla-assurance-optical-yang/
¶ A Publication-Point-Based Incremental Validation Procedure for RPKI Relying Parties
-
Champions
Yingying Su (suyy@mail.zgclab.edu.cn)
Lancheng Qin (qinlc@mail.zgclab.edu.cn) -
Project Info
This project demonstrates a publication-point-based incremental validation procedure for RPKI Relying Parties (RPs). The goal is to reduce repeated validation work after repository synchronization while preserving the same validated output as full top-down validation.
The RP project supports:
-- building a publication point cache after initial top-down validation;
-- full validation when a CA publication point is new or when its effective resource context changes;
-- publication-point-level reuse when the CA_ID, ca_effective_resources, manifest, and CRL are unchanged;
-- object-level reuse when the manifest changes but the CA_ID and ca_effective_resources remain unchanged, with re-checks for validation time and CRL status before reuse;
-- collecting metrics such as running time, PP cache hit/miss rate, PP-level reuse rate, object-level reuse rate, and validation output statistics. -
Hackathon Plan
-- Run our RP, Routinator, rpki-client, and FORT in an initial repository synchronization followed by full validation.
-- Run the same implementations after incremental repository synchronization followed by full RPKI object validation.
-- Run our RP after incremental repository synchronization with publication-point-based incremental validation enabled.
-- Compare running time, cache hits/misses, PP-level and object-level reuse behavior, and validated output, and show the results in the monitoring dashboard. -
Related Documents
-- https://datatracker.ietf.org/doc/draft-su-sidrops-rpki-rp-incremental-validation/
¶ MUD, TEAP, and IoT stuff
- Champions
Eliot Lear (lear@lear.ch) - Project Info
This project looks to improve hostap to match TEAPv2 [1] as well as to look at improvements to both MUD improvements and improvements to MudMaker[2].
-- Most of the code for TEAPv2 should be present a fork of hostap, but some additional work is needed to the TLS interface.
-- On the MUD front, we need to look at handling a new use case, which is that of IT/OT contract management, as well as cleaning up some bits and bobs, like multicast and broadcast.
¶ DRIP End-to-End Implementation (DNS/DNSSEC)
-
Champions
Sandoche BALAKRICHENAN (sandoche.balakrichenan@afnic.fr)
Nathan LE SAUSSE (nathan.le_sausse@telecom-sudparis.eu)
Lourenço Alves Pereira Jr (ljr@ita.br)
Flavio Souza (flavioluiz.ssouza@gmail.com) -
Project Info
This project aims to demonstrate an end-to-end implementation of the DRIP (Drone Remote ID Protocol) architecture, with a particular focus on the DNS and DNSSEC components specified in RFC 9886.
Current implementation includes:
-
A proof of concept implementing the DNS resolution architecture described in Figure 3 of RFC 9886, enabling DRIP identifiers to be resolved through the DNS.
-
A DRIP cryptographic implementation integrated with a Remote ID implementation running on ESP32 hardware.
-
A DNSSEC-enabled DRIP namespace, providing a complete chain of trust from the DRIP apex through delegated registry zones to registrant records.
-
Goals for the IETF Hackathon
- Integrate the DNS/DNSSEC implementation with other ESP32-based DRIP implementations developed within the community.
- Enable DNSSEC validation on the observer so that DNS responses are authenticated before the retrieved public key is used.
- Complete the end-to-end verification workflow, where the observer first validates the DNSSEC chain of trust and then verifies the DRIP cryptographic signature carried in the Remote ID message.
- Test interoperability between independent DRIP implementations and identify implementation issues.
- Demonstrate interoperable “running code” for the complete DRIP architecture and gather implementation experience to support ongoing work in the DRIP Working Group.
¶ Minimal multicast extensions for QUIC
- Champions
Louis NAVARRE (louis.navarre@uclouvain.be)
Vany INGENZI (vany.ingenzi@uclouvain.be)
Anthony DOERAENE (anthony.doeraene@uclouvain.be) - Project Info
The objective of this hackathon is to implement a minimal extension of multicast inside the QUIC protocol.
Two drafts already explore how to extend QUIC with multicast support:
draft-jholland-quic-multicast
draft-navarre-quic-flexicast
Though they offer benefits, the two approaches already embed numerous features that go beyond the basic framework to efficiently deliver the same data to multiple recipients.
In this hackathon, the objective is to implement a minimal, interop-ready multicast extension in QUIC as a proof of concept.
- Related documents
https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/
https://datatracker.ietf.org/doc/draft-navarre-quic-flexicast/
¶ RATS CoSERV - demo new features
-
Champions
Paul Howard (paul.howard@arm.com) -
Project Info
CoSERV has introduced a new query mechanism based on RIM identifiers instead of environments.
This project is to implement the new query style and to show a simple end-to-end demonstration of it interoperating between the Rust and Go implementations.
Rust support for CoSERV is here.
Go support for CoSERV is here.
- Related Documents
https://datatracker.ietf.org/doc/draft-ietf-rats-coserv/
¶ MyTerms - LF and browser integrations
-
Champions
Ben Curtis (ietf@nowsci.com) -
Project Info
MyTerms establishes a technical framework for Verifiable Contractual Agreements (VCAs) between individuals and entities, allowing individuals to proffer their privacy and data usage requirements in a format that can be read, acknowledged, and agreed to by both humans and machines. -
Hackathon Plan
- Architecture: Integration into Linux Foundation's community project - LF is building a verifiable community system through Decentralized Trust Labs who's initial target community is the Linux kernel developers for which MyTerms has been identified as a platform for TOS agreements. This part of the hackathon will be to architect how MyTerms could be integrated.
- Development: Browser-based signing - Building out a client-side implementation to handle the negotiation and cryptographic signing of agreements directly within web browsers that can interface with password managers.
- Any other interesting ideas
-
Related documents
-
Links
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-teapv2/)
[2] https://datatracker.ietf.org/doc/draft-lear-iotops-mudextras/
¶ Quality of Outcome (QoO): Evaluation, Tooling, and Ecosystem Development
-
Champion
Ike Kunze (ike.kunze@cujo.com) -
Project Info
Quality of Outcome (QoO) is an IPPM framework for assessing network quality in the context of application requirements. The QoO draft is currently in the RFC Editor Queue. This project aims to help grow the QoO ecosystem through practical experimentation, tooling, implementation experience, and discussion around application profiles and measurements. A pre-built Docker-based testbed provides network emulation, active and passive measurements, live QoO score calculation, and Grafana dashboards. Participants can bring applications to test or use provided examples. The focus is not on validating QoO itself, but on exploring questions such as:- Which application profiles are useful?
- When are category-based profiles sufficient?
- How do different impairment types affect QoO scores?
- How do different measurement approaches influence scoring?
-
Hackathon Activities
-
QoO under Network Impairments: latency, jitter, and (burst) packet loss
-
Comparing Network Quality Metrics: QoO, responsiveness, and underlying network measurements
-
Comparing Measurement Approaches: active measurements (e.g., ping, TWAMP) and passive measurements (e.g., based on TCP or QUIC semantics)
-
Exploring QoO Profiles: application-specific versus category-based profiles
-
-
Expected Outcomes
- Evaluate multiple applications under controlled network impairments
- Compare QoO with other network quality metrics
- Identify scenarios where impairment type or profile selection materially affects scoring
- Identify opportunities for future QoO profiles, tooling, measurements, and implementations
- Generate implementation and operational experience that may help inform future community guidance, profile catalogs, or ecosystem development as QoO adoption matures
-
Related Documents
- QoO draft: https://datatracker.ietf.org/doc/draft-ietf-ippm-qoo/
- Hackathon Network Emulation Framework: https://github.com/cj-ike-kunze/ietf-126-hackathon-qoo (will be made available before the hackathon)
¶ I2ICF Project for Physical AI Agents
-
Champions
Jaehoon Paul Jeong (pauljeong@skku.edu) -
Project Info
The goal of the Interface to In-Network Computing Functions (I2ICF) is to demonstrate the feasibility of an I2ICF framework that translates natural language intent into real-time tracing and detection actions for moving objects. The framework provides a structured architecture and a collection of interfaces that enable cloud-based users to control and monitor mobile systems, such as robotic AI agents and other moving devices. In this work, a robot car fuses real-time camera and LiDAR data to detect and track a target object. An AI-based intent inference server converts natural language commands into structured tracing and detection workflows. -
Specifications
[draft-jeong-nmrg-i2icf-problem-statement-00]
[draft-jeong-nmrg-i2icf-framework-00]
[draft-an-nmrg-i2icf-cits-02]
¶ I2NSF Project for Integrated 5G Edge Security Services
- Champions
Jaehoon Paul Jeong (pauljeong@skku.edu) - Project Info
This work introduces a mobility-aware security framework for 5G edge networks based on the I2NSF architecture. It uses Intent-Based Networking (IBN) to translate high-level security intents into network-level and application-level policies. Network policies are enforced by distributed NSFs near UPFs, while application policies are applied on UEs. During an N2-based handover, the active policy context is transferred to the target NSF and activated before the user-plane path is switched. Closed-loop monitoring and analytics help maintain consistent policy enforcement across distributed 5G edge environments. - Specifications
[draft-ahn-nmrg-5g-security-i2nsf-framework-02]
¶ IPWASN Project for IPv6 Satellite Networking
- Champions
Jaehoon Paul Jeong (pauljeong@skku.edu) - Project Info
This work proposes use cases and a problem statement for IPv6Wireless Access in Satellite Networks (IPWASN). IPWASN aims at the IPv6-based wireless access in Non-Terrestrial Networks (NTNs), that is, satellite networks. It considers NTN characteristics such as dynamic topology, multi-hop communication over inter-satellite links, High-Altitude Platform Station (HAPS)-assisted relay paths, frequent handovers, variable link quality, and intermittent connectivity. Based on these characteristics, this document identifies key challenges in applying existing IPv6 protocols to NTN environments. It also analyzes the applicability of current IPv6 mechanisms and outlines requirements to support efficient data forwarding, Quality of Service (QoS), Segment Routing (SR)-based traffic engineering, and connectivity in satellite-based networks. This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy). - Specifications
[draft-lee-6man-ipv6-satellite-networks-00]
¶ Agent Communications Internet Protocol
- Champions
Qiangzhou Gao (gaoqiangzhou@huawei.com)
Bo Li (libo391@huawei.com)
Nan Geng (gengnan@huawei.com)
Zhiyuan Wang (wangzhiyuan51@huawei.com)
Chong Zheng (zhengchong6@huawei.com)
Guanming Zeng (zengguanming@huawei.com)
Li Zhang (zhangli344@huawei.com)
Chengxiang Li (lichengxiang11@huawei.com) - Project Info
Building on the foundation established at IETF 125, this project defines ACIP (Agent Communications Internet Protocol), a gateway-centric protocol enabling cross-domain Agent discovery, registration, and routing. ACIP introduces an architecture where devices are bound to specific Agents (underlay relationship), Agents register their skills to corresponding Gateways, and Gateways discover each other to route cross-domain calls — ensuring all inter-Agent communication goes through Gateways with no direct peer-to-peer links. The protocol includes core modules for Agent registration, Gateway discovery and synchronization, and cross-domain relay routing. Taking the home broadband scenario as a specific use case, this project demonstrates the workflow through an Elderly Fall Detection scenario: millimeter-wave radar detects a fall, the Home Personal Assistant Agent orchestrates the response by calling the See Link Agent via its Gateway to confirm the fall through the home camera, and the Digital Life Agent to retrieve vital signs via the smart band — followed by automated SMS notification to family members and video call connection to the smart screen. This demonstration reflects the feasibility and practical value of ACIP in enabling efficient, automated inter-Agent collaboration across isolated cloud domains for carrier-grade home broadband services.
¶ DDoS Defense with CoAP Task Resources
-
Champions
Linzhe Li (lilz@zgclab.edu.cn)
Yujia Gao (gaoyj@zgclab.edu.cn) -
Project Info
This project demonstrates how CoAP Task Resources can be used to deploy DDoS defense policies as observable asynchronous tasks.In the demo, a control center acts as a CoAP Task Client and a DDoS cleaning device acts as a CoAP Task Server. The control center creates a task for sequential policy deployment, including cleaning policy, ACL, BGP FlowSpec, BGP diversion, and mitigation verification. The cleaning device reports task state, progress, diagnostics, and per-step results through
/tasks/{id}.
- Related Drafts:
Don’t see anything that interests you? Feel free to add a project to the list, sign up as its champion, and show up to work on it. Note: you must login to the wiki to add content. If you add a new project, we suggest you send an email to (hackathon@ietf.org) to let others know. You may generate interest in your project and find other people who want to contribute to it. TEMPLATE: Copy/paste and update the following template to add your project to the list:
### Your Project
- **Champions**
name and email
- **Project Info**
project description
To edit the wiki, log in using your IETF Datatracker login credentials. If you don't yet have an IETF Datatracker account, you may get one by going here and requesting a new account.