¶ IETF 120 Hackathon
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: 20 - 21 July 2024 (Saturday - Sunday)
Where: Hyatt Regency, Vancouver, Canada
Room: Regency D/E/F
| Gold Running Code Sponsor | Bronze Running Code Sponsors |
|---|---|
 |
  |
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 PDT, GMT-7)
¶ Saturday, 20 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, 21 July
- 09:30 : Room opens - pastries and coffee provided
- 12:30 : Lunch provided
- 13:30 : Hacking stops, prepare brief presentation of project
- 14:00 : Project results presentations
- 16:00 : Hackathon ends
- 17:00 : Tear down complete
Related activities before and after the Hackathon weekend
¶ Hackdemo Happy Hour
- Share your Hackathon project with the IETF community
- Monday, 22 July, Time: 18:30 - 19:30, Room: Regency Hallway
- View the schedule or reserve space for your team/project
- Reservations for space must be made by 13:00, Monday 22 July
¶ Shared Workspace
- Space for groups to gather and collaborate on running code
- Tuesday - Friday, 22-26 July, Room: Brighton/Kensington/Constable
- View the schedule or reserve space for your team/project
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
¶ Meeting Materials
- Code can be accessed from IETF Hackathon GitHub, or from links provided within project descriptions below.
- Request to be added to IETF GitHub organization by sending your GitHub ID to (hackathon-chairs@ietf.org).
- Results of Hackathon projects should be uploaded to GitHub. See the README for details.
- The Hackathon Results presentations from Sunday, 14:00-16: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 org is used for Hackathon presentations and contains repositories for some Hackathon projects.
- 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.
- IETF Hackathon teams should upload their Hackathon project presentations to GitHub.
- You must be a member of the IETF-Hackathon GitHub org to upload a new presentation or update/replace an existing presentation
- To be added as a member, see details in the README
- DO NOT WAIT until just before Hackathon project presentations start or your request may be lost in the chaos
¶ Network
Access to the IETF network
The NOC team has an ongoing experiment that allows you to join the IETF network remotely as well as at an IETF meeting venue.
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.
¶ Formal Analysis of Attested TLS for Confidential Computing
-
Champions
- Muhammad Usama Sardar (muhammad_usama.sardar at tu-dresden.de)
-
Project Info
- 3 main ways to combine attestation in TLS
- Pre-handshake attestation (Tutorial slides)
- Intra-handshake attestation (Internet draft)
- Post-handshake attestation (Sec. 4 in this draft)
- 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. If you are interested, please contact by email.
- Tool for formal analysis: ProVerif (other tools are welcome too)
- 3 main ways to combine attestation in TLS
-
Background on Attestation
¶ 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 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.
For this Hackathon event, the goal is to introduce people to Thread and OpenThread programming. This Hackathon event is open to all — Thread Group membership is not required, though of course Thread Group members are also welcome to participate. If you plan to participate in the Thread work at the Hackathon (on-site or remotely), please add your name to the participant list. If you already have a Thread developer board and the OpenThread build environment on your laptop, please bring that. If not, we will have a few extra Thread developer boards available and we can help you get the build environment set up. For people totally new to Thread development, we have some recommendations from Allie Clifford and Ann Olivo.
Below is a partial list of project ideas. Other ideas are welcome and encouraged. Please feel free to add suggestions to the project list. -
Participants
Stuart Cheshire (Apple)
Suvesh Pratapa (Silicon Labs)
Jot Kailay (Joto)
François Michel (UCLouvain)
Q Misell (Max-Planck-Institut für Informatik)
Ryan Wang (University of British Columbia)
Bernhard Degen (University of Twente)
Alphan Arseven (Arroba Labs)
Ted Lemon (Apple) -
Project Info
-
SSH daemon for OpenThread. Historically the way engineers interact with Thread developer boards has been by physically plugging them into a computer’s USB port and using a serial port console program to access OpenThread’s command-line interface. Now that OpenThread includes TCP support (contributed by Sam Kumar) it becomes feasible to access the same command-line interface over the network using ssh. The goal of this project is to identify a compact implementation of ssh suitable for constrained embedded devices, and integrate that into OpenThread. Particularly for testbeds with hundreds of Thread devices, being able to log in and transfer log files using the network is much better than needing hundreds of USB cables to connect all the devices to a computer.
-
Native Thread Commissioning for Matter. Current Matter devices that operate over Thread incur the cost of Bluetooh hardware and firmware, which is only needed for initial commissioning. This adds hardware cost to Matter devices for something that most users only do once in the lifetime of the product. It would be better to perform Matter commissioning for Thread devices via the Thread radio itself, using the Thread MeshCoP (Mesh Commissioning Protocol) mechanism. Some minor work is needed to implement tunnelling the Matter commissioning data (e.g., Device Attestation) over Thread MeshCoP.
-
Lightweight QUIC for OpenThread. Both TCP and QUIC are sophisticated transport protocols, suitable for efficiently transporting small and large amounts of data. Zero-round-trip connection setup in both TCP and QUIC allows for small request/response exchanges in a single round-trip. Sliding-window flow control and refined congestion-control algorithms enable TCP and QUIC to transfer large amounts of data, quickly, reliably, and efficiently, without unreasonably disrupting other traffic sharing the network. OpenThread includes TCP, and it would be good to complement that with support for QUIC as well.
-
General OTA (over-the-air) Firmware Update. Today firmware is typically installed into the flash memory of a Thread developer board via a USB port. It would be very helpful to have a general way of updating firmware over IP — particularly for people working with hundreds of Thread devices instead of just two or three.
-
Sensor Data Batched Upload. Many types of sensors, like temperature sensors, collect data at regular intervals, which should be uploaded to a data collection server in a reasonably timely manner when the Thread mesh is idle enough that such uploads will not disrupt other operations. Now that OpenThread has TCP, it would be useful to have a general mechanism for uploading this kind of sensor data.
-
Live Thread Diagnostics. When a large Thread mesh is not behaving as expected, it would be very useful to have a general mechanism for fetching information from nodes on the mesh regarding their connectivity to neighbors and other similar diagnostic data.
-
Thread Network Optimization Assistant. Create a Thread network visualizer (or enhance an existing one) to analyze the current network state, identify inefficiencies, and provide prioritized, actionable recommendations for network optimization (e.g., node placement, router selection).
-
Thread Network Merge Visualization Tool. Develop a visualization tool to analyze and evaluate the feasibility of merging two or more Thread mesh networks by comparing their topologies, performance metrics, and service landscapes.
-
Thread Latency Investigations. One of the main uses of Thread is for home automation, and when you are using an IP network to turn lights on and off, quick response times (under ¼ second) are very desirable. At the same time, an IP network like Thread is ideal for installing firmware updates and similar large data transfers. Because Thread is a low-power low-throughput technology aimed at low-cost devices that can run for years on a single battery, intelligent queue management (including ECN and L4S) is vital so that the network can support large bulk transfers while still maintaining good responsiveness for control operations. The Thread 1.3 specification includes requirements for delay-aware queue management, and there are many research opportunities related to analyzing this behavior and perhaps finding ways to make it even better.
-
Thread Credential Sharing. Wi-Fi generally utilizes a user-visible password (when we’re not using 802.1X certificates), but Thread opts instead for strong cryptographic keys, which are arguably more secure, but harder for humans to deal with. When we want to have multiple Thread devices participate in a single Thread mesh, they all need to know the key to the mesh. Work is underway on developing a safe secure way to perform device-to-device key transfer, and this Hackathon will be a good opportunity for the people working on that to get together and do some interop testing and debugging.
-
¶ Validate Configured Subscription YANG-Push Publisher Implementations
-
Champion(s)
Thomas Graf (thomas.graf @ swisscom.com)
Yannick Buchs (yannick.buchs @ swisscom.com) -
Draft Specifications
https://datatracker.ietf.org/doc/html/rfc8639
https://datatracker.ietf.org/doc/html/rfc8641
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang
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-tgraf-netconf-notif-sequencing
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-kafka-integration -
Project Info
Validate three YANG-Push configured subscription vendor implementations in terms of configuring periodical and on-change subscriptions and validating subscription state change and push-update and push-change-update notifications according to RFC 8639 and 8641.
Validate draft-ietf-netconf-udp-notif and draft-ietf-netconf-distributed-notif packet format on the wire.
Validate first YANG-Push extensions enabling Apache Kafka integration accoring to draft-ietf-nmop-yang-kafka-integration.
- Repository
https://github.com/network-analytics/ietf-network-analytics-document-status/tree/main/120/Hackathon
¶ Implement find relationship solution with Augmented-by list in ietf-yang-library
-
Champion(s)
Zhuoyao Lin (zhuoyao.lin1 @ huawei-partners.com)
Benoit Claise (benoit.claise @ huawei.com) -
Draft Specifications
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library-augmentedby/ -
Project Info
Implement the ietf-yang-library augmentedby list to the find-relationship solution of libyangpush(YANG push receiver component of the Data Mesh Architecture defined in draft-ietf-nmop-yang-message-broker-integration).
Demonstrate how the additional list improve the performance of the Data Mesh architecture use case. -
Repository
https://github.com/network-analytics/libyangpush
https://github.com/Zephyre777/draft-lincla-netconf-yang-library-augmentation.git
¶ Antagonist (ANomaly TAGging ON hISTorical data)
- Champions
- Vincenzo Riccobene (vincenzo.riccobene@huawei-partners.com)
- Wanting (Wanting.Du@swisscom.com)
- Antonio Roberto (antonio.roberto@huawei.com)
- Thomas (Thomas.Graf@swisscom.com)
- Project Info
Antagonist is a tool supporting the tagging of historical timeseries data. This is envisioned to support Network Anomaly Detection and it is created with the purpose of supporting network operators tagging their data with network anomaly related metadata. - Hackathon plan
Antagonist currently exists as a PoC. The objective for this hackathon is to improve the system design, extend the validation of the models defined in the drafts below, and showcase integration with third parties components. - Specifications
- Repositories
Github repo: https://github.com/vriccobene/antagonist
¶ IPsec: IP-TFS in Linux (swan support)
-
Champions
Christian Hopps (chopps@chopps.org) -
Project Info
IP-TFS in Linux is the implementation of IP-TFS in Linux. The code is nearing the point of merging and the netlink API is stable. As such it's time to start extending the swans to support configuring IP-TFS. Plan on adapting existing strongswan code published previously. Participants welcome to help or bring support to other swans (libre).
¶ BMWG - YANG model for management of Network Tester
- Champion(s)
- Vladimir Vassilev (vladimir@lightside-instruments.com)
- Project(s)
- Specifications
- Repositories
- Scripting - YANG/NETCONF benchmark orchestration code
- Software - YANG/NETCONF device side code
- FPGA -HDL
- Hardware - board design
- Getting started - walk-through
¶ vCon - Virtual Conversation Container
- Overview
WG: vCon
I-D: vCon container
Repos:
One of the primary goals of vCon is to ease and standardize the integration and data transfer between enterprise or contact center:
- Communications systems (email, sms, web chate, voice and video calls)
- Data consumer or customer data platform
- AI, ML and algorithmic analysis services and model training
- CRM systems
-
Champions
Dan Petrie dan.ietf@sipez.com -
Hackathon Objective
The goal for this hackathon is to implement and test portions of the vCon I-D that have not been well tested. -
Hackathon Work Items
-
JSON/CBOR conversion and verification using vCon CDDL
-
vCon filter_plugin and server processor for redaction
- Use the Captial One DataProfiler to identify PII in the transcript and create a redacted vCon that refers to the encrypted original, unredacted vCon.
- Redact the audio in the vCon using the transcription time stamps of the redacted text
- Redact the video in the vCon using the transcription time stamps of the redacted text
-
py_vcon_server vCon processors:
Create VconProcessor plugins for the vCon server. The init and processor method of the VconProcessor abstract interface need to be implemente using existing vcon methods.-
sign
Use python_vcon.Vcon.sign method -
verify
Use python_vcon.Vcon.verify method -
encrypt
Use python_vcon.Vcon.encrypt method -
decrypt
Use python_vcon.Vcon.decrypt method -
slack notification
Use the approach described in: How to Send a Message to a Slack Channel Using Python to implement a VconProcessor plugin to send slack messages in a similar way to how the SendEmail VconProcessor works.
-
-
¶ Testing congestion control algorithms
- Champions
- Reese Enghardt (ietf@tenghardt.net)
- Related Groups
- Project Info
- Work on congestion control testing: Simulation, testbeds, AB testing, or any other way of testing
- Hack on tooling, test cases, or the congestion control algorithm implementation itself
- Idea: Design test cases based on 5033bis, the proposed new BCP on Specifying New Congestion Control Algorithms
- Testing draft-ietf-tsvwg-careful-resume
¶ QUIC profiling for Deep Space
- Champions
Marc Blanchet, marc.blanchet@viagenie.ca - Project Info
IP can be used in deep space networking with some profiling, especially for QUIC. Work has progressed a lot in the recent months on which QUIC configuration parameters are needed for this use case. We used the Quinn QUIC stack (see QUIC in space and QUIC workbench) since pretty much all necessary configuration parameters were already available in the API. This hackathon is about externalizing the needed configuration parameters of other QUIC stacks in order to be usable in deep space. Depending on the participants interests, we will choose at the beginning which ones we want to modify and create PRs. Feel free to contact the organizers in advance for questions.
¶ Digital Map for ISIS and OSPF
-
Champions
- Oscar Gonzalez De Dios (oscar.gonzalezdedios@telefonica.com)
- Olga Havel (olga.havel@huawei.com)
- Benoit Claise (benoit.claise@huawei.com)
- Sherif Mostafa (sherif.mostafa@huawei.com)
- Pierre Francois (pierre.francois@insa-lyon.fr)
- Vivekananda Boudia (vivekananda.boudia@insa-lyon.fr)
-
Specifications
- https://www.rfc-editor.org/rfc/rfc8345
- https://www.rfc-editor.org/rfc/rfc8944
- https://www.rfc-editor.org/rfc/rfc8346
- https://datatracker.ietf.org/doc/draft-ogondio-nmop-isis-topology
- https://datatracker.ietf.org/doc/draft-ogondio-nmop-ospf-topology
- https://datatracker.ietf.org/doc/html/draft-havel-nmop-digital-map-concept-00
- https://datatracker.ietf.org/doc/html/draft-havel-nmop-digital-map-01
- https://datatracker.ietf.org/doc/draft-davis-opsawg-some-refinements-to-rfc8345
- https://datatracker.ietf.org/doc/rfc9130/
- https://datatracker.ietf.org/doc/rfc9129/
-
Project Info
- The goal is to demonstrate how operators can use the IETF Topology Yang models to represent a real carrier IP/MPLS network.
- We start with one particular problem space: How to use IETF topology model to represent a real carrier network based on IS-IS and OSPF domains for planning/simulation purposes.
- We want to demonstrate if RFC8345 is the suitable standard for representing the multi-layered topology for Digital Map and show the models comparison with and without the identified gaps.
- This IETF120 Hackathon will initially focus on generic topology queries, and compare IS-IS topology and OSPF topology drafts with RFC8345 versus RFC8345bis (gaps identified in RFC8345) approaches.
- We would also show how we can retrieve performance metrics or configuration attributes (defined in RFC9030 or RFC9129 and retrieved via device API) northbound from the Controller via RFC8345 API and its IS-IS and OSPF Augmentation.
- The next IETF121 Hackathon will start looking at simulation/emulation details.
-
Related Groups
- Network Management Operations (nmop) Working Group
¶ Exploring Implementation Approaches for Merkle Tree Ladder Mode Signatures for DNSSEC
- Champions
Burt Kaliski (bkaliski@verisign.com)
Andrew Fregly (afregly@verisign.com) - Specifications
- https://datatracker.ietf.org/doc/draft-fregly-dnsop-slh-dsa-mtl-dnssec/
- https://datatracker.ietf.org/doc/draft-harvey-cfrg-mtl-mode/
- Project Info
This hackathon will allow participants to experiment with a DNS zone signed with SLH-DSA-MTL signatures as defined in the draft "Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC". The draft defines an implementation of draft "Merkle Tree Ladder (MTL) Mode Signatures". Merkle Tree Ladder (MTL Mode) provides a mode of operation that can reduce the size and processing impact of Post-Quantum Cryptographic signature algorithms. In this hackathon, participants can interact with two of the authors of the MTL Mode draft to explore the characteristics of MTL Mode relative to DNS resolver and authoritative name-server implementation. The example signed zone [from the SLH-DSA-MTL draft] will serve as a basis for explaining signing, verification and resolution processes related to SLH-DSA-MTL signatures in the DNSSEC use case. - Related Groups
- DNS Operations (DNSOP) Working Group
- Crypto Forum Research Group (CFRG)
¶ 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 to test RFC/draft compliance, interoperability, and performance in various conditions.
- As has been the case at several previous IETFs, the intent is to begin work during the Hackathon, and then continue in the Brighton room (fourth floor) for the rest of the week.
- Specifications
RFC9330
RFC9331
RFC9332
draft-ietf-tcpm-accurate-ecn-28
¶ Rapid Automated Synchronization of DNS Delegation Data From Child to Parent
- Champions
- Johan Stenstam (johan.stenstam@internetstiftelsen.se)
- Project Info
Add new functionality to a working open source nameserver implementation (written in Go) to
provide fully automatic management of delegation information between child zones (both
DNSSEC-signed and unsigned) and parent zones.
This is a continuation of the work we did during the IETF 119 Hackathon.
Detailed project suggestions: https://github.com/johanix/hackathon120/
-
Specifications
-
Repositories
Github repo for the code we will use as a starting point: (https://github.com/johanix/tdns)
¶ IETF Next Conference App - Cancelled because I'm stuck in Salt Lake City
- Champions
Tom Pusateri pusateri@bangj.com - Cancelled - Project Info
We will be building the open source conferene app and working on the calendaring feature plus other features you might want to add. Please bring a modern macOS machine with the latest XCode installed. - Android Interest?
If anyone wants to work on an Android version, I would be interested in contributing expertise with the APIs but I do not have any Android programming experience. It would be good to have an identical Android app and if the intention is to look similar, you can use the same name. - Repositories
https://github.com/pusateri/IETFNext/
¶ Post-Quantum Cryptography (PQC) in X.509, Signatures, KEMs, and protocols
-
Champion(s)
John Gray (john.gray@entrust.com)
Mike Ounsworth (mike.ounsworth@entrust.com)
Julien Prat (julien.prat@cryptonext-security.com)
Massimiliano Pala (massimiliano.pala@wellsfargo.com) -
Draft Specifications
https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/
https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/00/
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/
https://datatracker.ietf.org/doc/draft-ietf-lamps-cert-binding-for-multi-auth/01/
https://www.ietf.org/id/draft-lamps-okubo-certdiscovery-00.html
https://datatracker.ietf.org/doc/draft-bonnell-lamps-chameleon-certs/
https://datatracker.ietf.org/doc/draft-gazdag-x509-hash-sigs/ -
Project Info
Purpose is to make use of PQ in real world X.509 structures like keys, signatures, certificates and protocols. This will allow us to test interoperability between different algorithm implementations, gain experience using these new algorithms, and provide feedback to the standards groups about practical usage in the real world.
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 120, we plan to setup and test the use of hybrid certificates for the TLSv1.3 protocol. The goal of the experiment is to explore different options for efficient use of hybrid certificates' and their multiple signature keys in the TLS protocol. We are looking for collaborations and ideas that can be then brought forward within the IETF and other standardization bodies (e.g., X9, ISO, etc.).
¶ STIR Certificate Transparency
- Champions
Chris Wendt (cwendt@somos.com)
Jeff Smith (jsmith@somos.com)
Rob Sliwa (rsliwa@somos.com) - Draft Specifications
https://datatracker.ietf.org/doc/draft-wendt-stir-certificate-transparency/ - Project Info
Our project focuses on improving Secure Telephone Identity (STI) by using Certificate Transparency (CT) to detect mis-issued certificates. Participants will adapt CT frameworks for telephone numbers, ensuring secure and authentic communications through advanced transparency protocols and mechanisms.
¶ Responsible DNS Integration
-
Champions
Swapneel Sheth (ssheth@verisign.com)
Andrew Kaizer (akaizer@verisign.com)
Bryan Newbold (bryan@blueskyweb.xyz) (update: out sick)
Nick Johnson (nick@ens.domains) -
Specifications
https://datatracker.ietf.org/doc/draft-sheth-dns-integration/ -
Project Info
Domain names have long been used as identifiers in applications ranging from TELNET and FTP to email services to web browsing. Recently, blockchain applications, decentralized protocols, and social media platforms have also emerged as new use cases for DNS domain names. How a DNS domain name is enabled for use as an identifier in each of these applications is known as a DNS integration. -
At this hackathon you will learn and discuss
- responsible DNS integration and why it is important.
- published measurement studies on responsible DNS integrations.
- recently published - https://datatracker.ietf.org/doc/draft-sheth-dns-integration/ on the motivations of using DNS domain names in new applications and the challenges of achieving a responsible DNS integration.
- the criteria that constitute a responsible DNS integration. What are we missing?
- two application developers integrating DNS domains and their lessons learnt.
- any feedback before adoption by a working group?
We welcome anyone interested about the draft to stop by and chat with available authors from Bluesky, Ethereum Name Service, and Verisign who are working on responsible DNS integrations.
¶ Interface to In-Network Functions (I2INF) Project
- Champion(s)
- Jaehoon Paul Jeong (pauljeong@skku.edu)
- Project(s)
- Demonstrate Interface to In-Network Functions (I2INF).
- Set up In-Network Computing Functions for mobile objects such as Software-Defined Vehicles (SDV) and Unmanned Aerial Vehicles (UAV) in terms of the configuration and monitoring of In-Network Functions.
¶ Multipath QUIC Interop
- Champions
Marcus Ihlar marcus.ihlar@ericsson.com - Project Info
Interop testing of Multipath QUIC implementations - see https://github.com/quicwg/multipath/wiki/Implementation-Draft-Interop
¶ Identifier Locator Network Protocol (ILNP)
- Champions
- Saleem Bhatti saleem@st-andrews.ac.uk
- Gregor Haywood (remote) gh66@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 to this is to deprecate the concept of an IP Address and replace it with addressing using a 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 demonstration is based on IPv6.
¶ Joint Exposure of Network and Compute Information
- Champions
- Jingxuan Zhang (jingxuan.n.zhang@gmail.com)
- Project Info
- Demonstrate how to use kafka to collect and aggregate network and compute information from multiple data sources.
- Extend ALTO to provide both network and compute information.
- Use CERN Rucio as a use case to demonstrate the how the joint exposure of network and compute information can improve the source selection of Rucio data movement in the large-scale scientific workflow.
¶ Collecting Consolidated ABNF From RFCs
- Champions
Dominique Hazael-Massieux dom@w3.org - Project Info
ABNF is used in many RFCs to describe the formal syntax of the associated specification. These ABNF declarations can be used to generate parsers, build tests, validators, documentation …. In a number of cases, the ABNF in a given RFC makes references to ABNF terms defined in other RFCs. The GitHub project above offers tooling to help consolidate these ABNFs into directly comprehensive versions. During the hackathon, interested participants could help extract and consolidate ABNF from more RFCs, explore how these consolidated RFCs could be exploited, approaches to automate more of the extraction/consolidation steps.
This project is inspired by the webref project where a number of reusable data and formal syntax from Web specifications get automatically extracted and curated, which have found adoption in a number of places (documentation, libraries, code/IDE support, automated testing of implementations, spec authoring tools, …)
¶ Sustainability Insights
- Champions
Per Andersson per.ietf@ionio.se - Project Info
- Our group is working on “Sustainability Insights", philatelist, label-tsdb, and POWEFF drafts.
- This is a continuation of the IETF 118 Hackathon where the group had worked on proof of concept
implementation of the green monitoring open source project. - Topics will be on proof of concept implementation of parts of the philatelist and label-tsdb drafts,
and connect the green-monitoring and sustainability-in-a-box projects.
- Draft specifications
- Code
- Webex (9:00am PCT - 8h)
¶ OAuth and atproto Identities
Champions
- Bryan Newbold bryan@blueskyweb.xyz (arriving Saturday afternoon, all day Sunday) (update: out sick)
- Boris Mann Boris Mann boris@bmannconsulting.com
- Chad Kohalyk chad@fission.codes
Project Info
atproto is an open federated social web protocol. The identity and auth system builds on open standards like DNS, DIDs (W3C), HTTP, and OAuth. The challenges of using OAuth between multiple independent hosts and multiple independent client software implementations are similar to challenges with ActivityPub, and an area of work at the IETF. This hackathon project involves prototyping and demonstrating interoperation between different types of clients and hosts.
Resources
- https://github.com/bluesky-social/indigo
- https://github.com/bluesky-social/cookbook
- https://github.com/bluesky-social/proposals/tree/main/0004-oauth
- https://atproto.com/specs/handle
- https://atproto.com/specs/did
¶ A possible attempt to use sconepro for RTC scenario
-
Champions
- Jiaxing Zhang zhangjiaxing20g@ict.ac.cn
- Qinghua Wu wuqinghua@ict.ac.cn
- Zhenyu Li zyli@ict.ac.cn
-
Project Info
- https://github.com/zhangjiaxingict/sconepro-rtc
- The goal of this project is to study the optimization of RTC application latency through feedback mechanisms. We have developed a simple RTC implementation based on QUIC that generates video frames according to the calculated sending rate and the size of packets in the sender's queue. We have also provided a basic feedback mechanism on network devices. The feedback implementation will be further refined in the future.
- The project utilizes Docker to simulate AP network devices, as well as the sender and receiver. We use Linux tc to emulate latency and dynamically changing bandwidth at the AP point.
- https://datatracker.ietf.org/doc/draft-joras-sconepro-video-opt-requirements/
¶ RESTful EPP implementation
- Champions
Maarten Wullink maarten.wullink@sidn.nl - Project Info
- https://datatracker.ietf.org/doc/draft-wullink-restful-epp/
The goal of this project is to create an implementation of RESTful EPP (REPP) API compatible with current EPP (extensions).
REPP is currently being discussed in the REGEXT working group and having running code will help towards creating a new RFC.
¶ Just DNS -- Generic DNS catch all
- Champions
- Shumon Huque shuque@gmail.com
- Yorgos Thessalonikefs yorgos@nlnetlabs.nl
- Willem Toorop willem@nlnetlabs.nl
- Project Info
A catch all for all the DNS things that don't already have a specific project.
¶ Ultra-Low Latency Cryptography
- Champion(s)
- Yumi Sakemi (yumi.sakemi@gmo-cybersecurity.com)
- Satoru Kanno (satoru.kanno@gmo-cybersecurity.com)
- Project Info
- In future communication technologies such as 6G, there are technical requirements that demand ultra-low latency and high levels of security. So, the purpose of this project is to achieve low-latency and highly secure cryptographic techniques targeting future communication technologies.
- TBD
- Paper at https://tches.iacr.org/index.php/TCHES/article/view/10279/9727
- We are currently recruiting collaborators who will join us in this project.
- Specifications
- https://datatracker.ietf.org/doc/draft-sakemi-areion/
- Work in progress
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.