¶ IETF 119 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: Saturday - Sunday, 16-17 March 2024
Where: Brisbane Convention & Exhibition Centre, Brisbane, Australia
Plaza Terrace Room, Upper Plaza Level
Sponsored by
| Gold Running Code Sponsor | Silver 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
Hackathon (all times are AEST, GMT+10)
¶ Saturday, 16 March
- 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, 17 March
- 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, 18 March, Time: 18:30 - 19:30, Room: PTR Concourse
- View the schedule or reserve space for your team/project
- Reservations for space must be made by 13:00, Monday 18 March
¶ Code Lounge
- Space for groups to gather and collaborate on running code
- Tuesday - Friday, 19-22 March, Room: P4
- 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.
¶ 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.
¶ 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)
Tomofumi Okubo (tomofumi.okubo@digicert.com)
Julien Prat (julien.prat@cryptonext-security.com)
Massimiliano Pala (director@openca.org) -
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-ounsworth-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
¶ Augmented-by Addition into the 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-lincla-netconf-yang-library-augmentation/ -
Project Info
Opensource implementation of the augmented-by list in ietf-yang-library, with netopeer/libyang.
Demonstrate how the additional list improve the performance of the Data Mesh architecture use case. -
Repository
https://github.com/Zephyre777/draft-lincla-netconf-yang-library-augmentation.git
¶ 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-netana-nmop-yang-kafka-integration -
Project Info
Validate two YANG-Push configured subscription vendor implementations in terms of configuring periodical and on-change subscription 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-netana-nmop-yang-kafka-integration.
- Repository
https://github.com/network-analytics/ietf-network-analytics-document-status/tree/main/119/Hackathon
¶ 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
¶ 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.Detailed project suggestions: https://github.com/johanix/hackathon119/
-
Specifications
-
Repositories
Github repo for the code we will use as a starting point: (https://github.com/johanix/tdns)
¶ Compact denial of existence for DNSSEC
-
Champions
- Shumon Huque
-
Project Info
Add CDE (Compact Denial of Existence) to authoritative name servers. On of them will be Drink -
Specifications
¶ SAV Open Playground
- Champions
- Yuqian Shi (shiyuqian at zgclab.edu.cn）
- Lancheng Qin (qlc19 at mails.tsinghua.edu.cn)
- Libin Liu (liulb at zgclab.edu.cn)
- Li Chen (lichen at zgclab.edu.cn)
- Project Info
- SAV Open Playground (SAVOP) is an open platform designed for the implementation and emulation of various source address validation (SAV) mechanisms
- Code: https://github.com/SAV-Open-Playground/
- Feel free to share your ideas at https://github.com/SAV-Open-Playground/savop/discussions
- Hackathon Plan
- Implementation of Signed SAVNET-Peering Information (SiSPI) object for deploying inter-domain SAVNET. For detailed information about the SiSPI object, please refer to the draft draft-chen-sidrops-sispi available at https://datatracker.ietf.org/doc/draft-chen-sidrops-sispi/.
- Implementation of a SAV information base (SIB): SIB consolidates SAV-related information from various sources, such as SAV-specific information, RIB, FIB, and RPKI ROA objects and ASPA objects.
- Implementation of an operation module: The operation module is designed to facilitate emulations of SAV mechanisms through configurations. We have designed a configuration template.
¶ 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 and validate an additional draft, recently submitted, for the definition of lifecycle and metadata of network anomaly lifecycle. - Specifications
- Repositories
Github repo: https://github.com/vriccobene/antagonist
¶ SAV-D
-
Champions
- Haoran Luo (HaoranMe@outlook.com)
- Shuisong Hu (Hi.shuisong@gmail.com)
- Longjie Wang (whhxd@outlook.com)
- Linzhe Li (lilz@zgclab.edu.cn)
-
Project Info
SAV-D is a distributed defense architecture based on Source Address Validation (SAV) technology, designed to improve the effectiveness of defenses against IP spoofing DDoS attacks. It achieves this by collecting and aggregating threat data from existing SAV devices and then distributing crucial information across a broad range of devices to significantly enhance network-wide defenses. Through its innovative approach of utilizing SAV devices as honeypots to gather threat data, and sharing attack detection information and IP blocklists with victims' defense systems, SAV-D aims to bolster the overall resilience of networks against sophisticated DDoS attacks. -
Hackathon plan
The purpose of this hackathon is to demonstrate the effectiveness of the SAV-D architecture in addressing DDoS reflection amplification attacks through experimental means, and to validate the draft submitted, which describes the overall architecture of SAV-D and its workflow. -
Specifications
https://datatracker.ietf.org/doc/draft-cui-savnet-anti-ddos/ -
Repositories
https://github.com/sava-anti-ddos/SAV-D
¶ Identifier Locator Network Protocol (ILNP)
- Champions
- Saleem Bhatti saleem@st-andrews.ac.uk
- Gregor Haywood (remote, St Andrews, UK) gh66@st-andrews.ac.uk
- Rodney Grimes rgrimes@freebsd.org
- Alistair Woodman awoodman@netdef.org
- Ran Atkinson
- 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.
¶ FRRouting doctor(s)
Probably colocated with ILNP table (see above) due to org overlap.
- Champions
- 🦄 David 'equinox' Lamparter equinox@opensourcerouting.org
- Project Info
FRRouting is a common choice when prototyping or implementing routing-related IETF drafts.We'reI'm here to help with any questions — code itself, building test setups, but also process related (aka "how do I get my code merged?", or "how do I even get started?") - Contact for remote
If you are remote and looking for help with the above, please send an e-mail directly to the people listed above; other communication channels might be missed. - Repositories
https://github.com/FRRouting/frr/
¶ Enhancing DNS delegation with DELEG
- Champions
- Ralf Weber dns@fl1ger.de
- David Lawrence tale@dd.org
- Project Info
Discuss the current deleg draft https://github.com/fl1ger/deleg as well as all other topics related to DELEG for the upcoming BOF
¶ Extended YANG Data Model for DOTS
- Champions
- Xiaohui Xie (xiexiaohui@tsinghua.edu.cn)
- Linzhe Li (lilz@zgclab.edu.cn)
- Yannan Hu (huyn@zgclab.edu.cn)
- Shibo Du (dsb20@mails.tsinghua.edu.cn)
- Jialin Niu (njl@bupt.edu.cn)
- Jinzhou Liu (liujzh@zgclab.edu.cn)
- Yong Cui (cuiyong@tsinghua.edu.cn)
- Project Info
RFC8612 defines the DOTS (DDoS Open Threat Signaling) protocol for the collaborative response to DDoS attacks, which can be used between any devices to convey collaborative information such as mitigation requests and monitoring data. As DDoS attacks and mitigation technology have evolved, DOTS can no longer meet some of the needs for collaborative mitigation. It is necessary to extend the DOTS data model to improve the speed of collaborative response and optimize collaborative mitigation strategies. In this project, we extend the Yang Data Model for DOTS and develop a prototype system to support and evaluate the extensions.
Please refer to the RFC drafts listed below for more info about the extensions. Advice and comments are very welcome! - Specifications
¶ Multipath QUIC
- Champion(s)
- Magnus Westerlund (magnus.westerlund@ericsson.com
- Project Info
- Interop testing of the current draft of Multipath QUIC.
- https://github.com/quicwg/multipath/wiki/Implementation-Draft-Interop
- Specification
¶ Hardware Evaluation of Multicast Source Routing over IPv6 on Experimental Network
-
Champion(s)
- Weihong Wu (wuweihong@bupt.edu.cn)
- Yuxin Jiang (jyxin@bupt.edu.cn)
- Yutong Zhao(zhaoyutong@bupt.edu.cn)
- Yunyi Tang (tangyunyi0708@bupt.edu.cn)
- Jiang Liu (liujiang@bupt.edu.cn)
- Pei Anbang(anbangpei@bupt.edu.cn)
-
Project Info
- Implement MSR6 TE and MSR6 TE with RLB on a testbed with 5 hardware P4 switches on CENI(China Environment for Network Innovations)
- Comprehensively analyze the hardware performance of MSR6 TE and MSR6 TE with RLB from the perspectives of Hardware Resource Usage, Delay, and Stability.
-
Specification
¶ NASR: Network Attestation for Secure Routing
- Champions
- Peter Chunchi Liu liuchunchi@huawei.com
- Meiling Chen chenmeiling@chinamobile.com
- Diego Lopez diego.r.lopez@telefonica.com
- Michael Richardson mcr+ietf@sandelman.ca
- Luigi Iannone luigi.iannone@huawei.com
- Project Info
- Network Attestation for Secure Routing (NASR) is targeted to help attest a specific network path and verify if actual forwarding result is compliant to the attested path and attributes.
- The goal is to forward data only on trusted devices, trusted operating environments or trusted services.
- NASR continues the discussion from IETF 118 Path Validation Side Meeting. A mailing list is created to continue the discussion. NASR side meeting will be held in IETF 119.
- Mailing List
- **Specification - Path Validation Problem Statement: draft-liu-path-validation-problem-statement-00
- NASR Use Cases and Requirements: draft-liu-nasr-requirements-01
- NASR Terminology: draft-richardson-nasr-terminology-00
- Vector Commitment-based Proof-of-Transit: draft-liu-vcpot-00
- Side Meeting Materials
¶ EAP-FIDO (or whatever it will be called at the end)
- Champions
- Janfred Rieckers rieckers@dfn.de
- Project Info
- EAP-FIDO is a new EAP method that leverages FIDO keys to facilitate an EAP login, primarily intended for WLAN logins
- Aim for the hackathon is to implement a proof-of-concept code against the current draft version
- Earlier Proof-of-Concept code (not compatible with current spec) is available here, this PoC code was presented at the Mobility Day at tnc23 in Tirana, Albania.
- Specifications
- Current EAP-FIDO draft: draft-janfred-eap-fido-02
¶ RPKI ASPA rpki-rtr support
- Champions
- Tom Harrison tomh@apnic.net
- Zen Chai zchai@apnic.net
- Rafael Cintra rafael@apnic.net
- Beau Gieskens beau@apnic.net
- Project Info
- Proof of concept updates for draft-ietf-sidrops-8210bis.
- Specifications
¶ vCon - Conversation Container
-
Champions
- Dan Petrie dan.ietf@sipez.com
-
Project Info
-
Specifications
-
Repository
¶ vCon - Right to Know/Forgotten
-
Champions
- Thomas Howe ghostofbasho@gmail.com
-
Project Info
This hack implements a Right to Know and a Right to be Forgotten application for vCons. This hack identifies which vCons contain personal information about a particular person, then provides the ability to report on what that personal information is, deletes it, and provides an audit trail.
In the age of AI, the balance between the right to know and the right to be forgotten has significant implications for personal data like voice recordings. As AI technologies increasingly rely on large datasets, including voice recordings for training purposes, the right to know can support transparency about how these datasets are collected, used, and shared by organizations. This transparency is crucial for understanding and monitoring AI's impact on privacy and individual rights.
However, the right to be forgotten plays a crucial role in empowering individuals to control their personal data, including voice recordings. Individuals can request the deletion of their voice data from databases to protect their privacy, especially in cases where the data is no longer necessary or relevant. This right is essential in preventing misuse of personal information and mitigating potential harms, such as unauthorized surveillance or identity theft.
The challenge lies in balancing these rights to ensure that AI development is both transparent and respectful of privacy. Regulations like the GDPR in the European Union provide frameworks for this, requiring clear consent for data collection and offering mechanisms for data deletion. -
Specifications
-
Repository
¶ 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 (Overview slides)
- Intra-handshake attestation (IETF draft)
- Post-handshake attestation (Project proposal)
- 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
- 3 main ways to combine attestation in TLS
-
Background on Attestation
¶ Mobile Object Network Mangement
-
Champions
Jaehoon Paul Jeong (pauljeong at skku.edu)
Yiwen Chris Shen (chrisshen at skku.edu)
Younghan Kim (younghak at ssu.ac.kr) -
Participants
Yoseop Ahn (ahnjs124 at skku.edu)
Mose Gu (rna0415 at skku.edu) -
Project Info
Software-Defined Vehicle (SDV) is a new player towards autonomous
vehicles in Intelligent Transportation Systems (ITS). An SDV is
constructed by a software platform like a cloud-native system and
has its internal network. To facilitate the easy and efficient
configuration of networks in the SDV, an intent-based
management is an appropriate direction. This project explores a
framework of intent-based management for networks, security, and
applications in SDVs so that they can communicate with other SDVs and
infrastructure nodes for safe driving and infotainment services in
the road networks. -
Internet Drafts
https://datatracker.ietf.org/doc/draft-yang-i2nsf-security-policy-translation/
https://datatracker.ietf.org/doc/draft-jeong-opsawg-intent-based-sdv-framework/ -
Youtube Demo
https://youtube.com/playlist?list=PLSd4MXSO7VifHLtETuyffZtsEAb6ed_Lq&si=NpfvCX-4Il4RLggh -
Github
https://github.com/jaehoonpauljeong/IBN-Network-Management/tree/main
¶ Dynamic Orbit Communication Protocol (DOCAP)
-
Champions
Yoshiki Uchida (uchiyoshi@sfc.wide.ad.jp) -
Participants
Ryuto Hisamoto (ryutology2030@duck.com) -
Project Info
The Dynamic Orbital Communication Adjustment Protocol (DOCAP) optimizes space communication by using heartbeat messages from orbital nodes like spacecraft to dynamically adjust communication margins based on speed and acceleration. The protocol currently sets a fixed MAX_SPEED_MPH (the assumed maximum speed), which may not reflect actual speed variations due to orbital maneuvers. To enhance communication efficiency and reliability, DOCAP aims to dynamically update MAX_SPEED_MPH based on real-time heartbeat data, ensuring accurate communication adjustments in the dynamic space environment. These topics will be discussed during the Hackathon. -
Discussion
Discord (https://discord.gg/jPAcfMKm)
¶ CBOR Deterministic Serialization
- Champions
Laurence Lundblade lgl@island-resort.com - Project Info
This is implementation and test vector work for recent CBOR drafts specifying
CDE (https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/) and dCBOR (https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/).
There is work on "preferred serialization" too.
The QCBOR implementation is in PRs here: https://github.com/laurencelundblade/QCBOR/pulls.
In particular, test vectors are at the end here (search for "conformance") https://github.com/laurencelundblade/QCBOR/blob/dcbor-decode/test/qcbor_decode_tests.c
¶ 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
¶ Where does IETF Work Come From and Where does the IETF Go?
-
Champion(s)
- Benson Muite (benson_muite at emailplus dot org)
-
Project Info
- Use information in the data tracker to find geospatial distribution of IETF participants.
- Find out what could help give a partially data driven approach to finding suitable candidate meeting locations.
- Code at https://codeberg.org/bkmgit/meeting-locations/src/branch/main/code
-
Specifications
- https://www.rfc-editor.org/rfc/rfc8719.html
- May need to be revised
-
Discussion
Contact by email, and/or raise issues associated with the code in the repository
¶ The HTTP Signature Authentication Scheme
- Champions
David Oliver david@guardianproject.info - Participants
David Oliver david@guardianproject.info
Abel Luck abel@guardianproject.info
François Michel francois.michel@uclouvain.be
David Schinazi dschinazi.ietf@gmail.com - Project Info
Existing HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. HTTP Signature Authentication proposes a new non-probeable cryptographic authentication scheme. See https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-auth/.
Our hackathon project is the first interoperability test between independent implementations of the specification.
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.