Markdown Version | Recording 1 | Recording 2

Session Date/Time: 01 Nov 2021 15:00

hackathon

Summary

The IETF 112 Hackathon kickoff session provided essential information and guidance for participants. The session highlighted the hackathon's core objective to accelerate IETF standards work by fostering open-source collaboration, improving protocol implementations, and attracting new developers. Detailed instructions were provided on leveraging online collaboration tools (Gather, Meetecho), project organization, utilizing the Hacknet (IETF VPN), and the process for Friday's results presentations, including GitHub repository usage and presentation guidelines.

Key Discussion Points

• Hackathon Goal: To accelerate IETF standards development by integrating open-source practices, improving implementation quality, and attracting a broader developer community to the IETF.
• IETF Note Well & Contributions: All IETF activities are governed by the Note Well. Hackathon code is typically licensed under its own open-source license (e.g., Apache 2.0), distinct from project presentations on Friday, which are considered IETF contributions. Inclusive language is strongly encouraged.
• Online Collaboration Environment:
  • Meetecho: Used for this kickoff and the final results presentation.
  • Gather: The primary virtual space for project teams, offering interactive tables for audio/video conferencing, shared whiteboards, and Hedgedoc-powered notepads. A mini-map aids navigation within the space.
  • Team Schedule: A wiki page where project teams can self-organize and post their meeting times and collaboration methods to accommodate global time zones.
• Project Engagement:
  • Comprehensive project descriptions and champion contact details are available on the hackathon wiki.
  • A "Lost and Found" section facilitates matching participants with specific skills to projects in need.
• Hacknet (IETF VPN): An IETF VPN network providing a shared Layer 2 environment for protocol testing. Access requires specific MicroTik devices and adherence to setup instructions.
• Results Presentations (Friday, 15:00-17:00 UTC):
  • Teams planning to present must sign up on the dedicated results presentation schedule page.
  • Presentations should be concise (maximum 5 minutes) and focus on accomplishments, technical learnings (especially those relevant to IETF working groups), and any cross-community collaboration.
  • Presentations are to be uploaded to the ietf-hackathon/ietf112-project-presentations GitHub repository.
  • Presenters must be members of the IETF GitHub organization, have two-factor authentication (2FA) enabled, and ensure their real name is associated with their GitHub account for repository write access.
  • Optional PowerPoint and HTML templates are available to assist with presentation preparation.
  • Teams will present their own slides live via audio/video sharing.
• IETF Hackathon GitHub Organization: Serves as a central location for project code repositories and the designated repository for results presentations.
• Sponsorship: CNEC was acknowledged as the running code sponsor for IETF 112.
• Support: Hackathon chairs (Charles and Barry) are available for assistance via [email protected] and within the Gather space.
• Suggestion: Investigate the feasibility of providing an ICS feed for the team schedule page to improve calendar integration.

Decisions and Action Items

• Policy Clarification: Code developed during the hackathon is typically governed by its own open-source license, whereas project presentations shared at the closing session are considered IETF contributions.
• Action Item (Project Champions):
  • Post your project's planned meeting times and collaboration methods on the wiki's team schedule page.
  • Sign up your project for a presentation slot on the results presentation schedule page for Friday's session.
  • Prepare and upload your project presentation to the ietf-hackathon/ietf112-project-presentations GitHub repository before Friday.
• Action Item (All Presenters):
  • Ensure you are a member of the IETF GitHub organization, have 2FA enabled, and your real name is associated with your GitHub account to enable presentation uploads.

Next Steps

• Throughout the Week: Project teams are to commence collaboration and self-organize meetings using Gather, Hacknet, and other preferred tools.
• Ongoing: All participants are encouraged to engage with project champions, explore the features of the Gather space (e.g., whiteboards, notepads), and utilize Hacknet for shared network testing if required.
• Prior to Friday's Session: All projects intending to present must have registered for a time slot and uploaded their presentation materials to the designated GitHub repository.
• Friday, 15:00-17:00 UTC: Attend the Hackathon Results Presentation session to share project outcomes and learn from other teams.

Session Date/Time: 05 Nov 2021 15:00

Hackathon Closing Session

Summary

The hackathon closing session featured presentations from various project teams, showcasing the diverse technical work accomplished during the week. The primary goal of the hackathon is to accelerate and improve IETF work by fostering implementation of standards as they are being defined, generating running code, and facilitating collaboration among developers and different SDOs. Teams presented their problem statements, solutions, key learnings, and next steps, covering areas from network performance and DNS security to IoT, WebRTC, and machine-readable specifications.

Key Discussion Points

• Hackathon Objectives Reiteration:
  • Speed up and improve IETF work by driving running code for standards under definition.
  • Enhance developer adoption and implementation of IETF standards.
  • Provide a platform for networking and collaboration across diverse backgrounds, including universities, other SDOs, and open-source organizations.
  • Engage non-typical IETF community members.
• IETF Note Well: Reminder for participants to be familiar with IETF processes, code of conduct, copyright, and IP disclosures.
• Presentation Guidelines: Presentations were encouraged to be brief (approx. 5 minutes), focusing on the problem solved, accomplishments, interesting highlights, learnings, and collaborations (within IETF or with other SDOs/open-source).
• Presentation Logistics: Teams were encouraged to use pre-uploaded slides via Meetecho's "share pre-loaded slides" feature for smoother transitions. Presentations proceeded in alphabetical order by project name as listed on the wiki/GitHub.

Project Presentations

• BMWG (Benchmarking Methodology Working Group)

  • Project: Containerized Infrastructure Performance Testing.
  • Goal: Control networking performance in containerized environments.
  • Accomplishments: Implemented containerized infrastructure with various network models, verified performance impacts based on configurations (SR-IOV, DPDK), tested BPP vs. OVS, and examined NUMA alignment's impact on vSwitch performance in multi-host scenarios.
  • Learnings: BPP generally outperformed OVS in multiple scenarios. NUMA alignment of vSwitch and NICs is critical, with different nodes showing slight degradation at higher packet sizes. Co-locating CNF and vSwitch on the same NUMA node significantly improved performance (10-50%).
  • Next Steps: Further investigation into NUMA alignment results, considering multiple vSwitch cases, and discussing findings with the IETF community.
  • Team: Collaborated with I2NSF and FPUA teams from SKKU.

• DNS Error Reporting (EER / EITHER)

  • Project: Implementing and testing Extended DNS Error Reporting (EER).
  • Goal: Inform authoritative servers about DNS resolution errors rather than just clients.
  • Accomplishments: Implemented a server-agnostic solution using eBPF to send unsolicited EER options. Conducted RIPE Atlas measurements (1000 probes) to assess resolver resilience to unsolicited EDNS options.
  • Learnings: 99% of resolvers handled the unsolicited EDNS option without issues, with the remaining 1% being inconclusive. The mechanism could provide DMARC-like confidence for DNSSEC deployment by offering feedback to domain operators. eBPF proved a powerful and flexible tool for augmenting existing name server installations.
  • Next Steps: Large-scale measurements to confirm resilience, explore a new IETF draft on "DMARC for DNS" for DNSSEC confidence.
  • Team: Willem Toorop, Tonko Park.

• I2NSF (Interface to Network Security Functions)

  • Project: Distributed Network Auditing System using Hyperledger Fabric.
  • Goal: Enhance the security and reliability of the I2NSF framework by using a distributed database for auditing.
  • Accomplishments: Integrated Hyperledger Fabric as a distributed database to store monitoring data collected by the I2NSF analyzer via a monitoring interface. Developed a web server for the secure controller to display this monitoring data.
  • Learnings: Distributed databases tackle data tampering (e.g., supply chain attacks) and eliminate single points of failure, improving overall framework security and reliability.
  • Next Steps: Store more data (security policies, NSF capabilities) in the distributed database.
  • Team: Collaborated with SKKU, BMWG, and IPWave teams.

• IPWave (Internet Protocol for Wireless Access in Vehicular Environments)

  • Project: Implementation of IPWave Context Over Navigation Protocol (CNP).
  • Goal: Enable communication between robot cars and web servers using CNP, incorporating W3C Vehicle Information Service Specification (VISS).
  • Accomplishments: Demonstrated CNP message delivery over C-V2X (Cellular V2X) in simulation (SUMO for mobility, OMNeT++ for C-V2X communication). Implemented vehicle structure and IPv6 stack for CNP in OMNeT++. Also demonstrated robot car sending sensing and speed information via Wi-Fi to a web server using VISS format.
  • Learnings: Showcased the feasibility of C-V2X for vehicular communication, complementing existing WAVE (IEEE 802.11p) stacks. IPWave working group should consider both WAVE and C-V2X for future vehicular communication.
  • Next Steps: Further integrate and test with different communication technologies.
  • Team: Collaborated with SKKU, BMWG, and I2NSF teams.

• ASPA (Autonomous System Provider Authorization)

  • Project: Laying groundwork for BGP AS Path Validation interoperability tests.
  • Goal: Create large-scale test harnesses and reference implementations for ASPA, focusing on validation cache-to-router communication.
  • Accomplishments: Implemented ASPA verification in the BGP SRx software suite (supporting draft version 8 and future algorithm corrections). Extended RFC 8210 to carry ASPA objects. Generated internet-scale ASPA data using CATA reference data (Oct 2020) and Route Views BGP updates, producing data sets for various unique AS paths (e.g., 70k customer registrations, 180k link relationships). Performed preliminary ASPA validation, observing expected valid/invalid/unknown rates for provider/customer scenarios.
  • Learnings: Initial results confirmed the AS path validation logic (valid, invalid for route leaks, unknown for insufficient info, unverifiable for AS_SET). Demonstrated the infrastructure for large-scale testing.
  • Next Steps: Run tests with multiple peers and different implementations for performance and interoperability comparison. Analyze gradual deployment scenarios to understand positive impact thresholds. Clean up and publish hackathon code on GitHub.
  • Team: Oliver Gasser.

• Ansible API Generator (Customized)

  • Project: Automatic generation of customized Ansible APIs for network automation.
  • Goal: Provide a tool to generate desired Ansible APIs for managing network devices via NETCONF/YANG, overcoming vendor-specific implementations and generalized API limitations.
  • Accomplishments: Developed Ansible-Gene, an automatic API generation tool that integrates into the Ansible framework. It supports customized input parameter checks and functionality. Successfully delivered L3VPN service to a device via an Ansible playbook using generated APIs.
  • Learnings: Documentation is as crucial as code for adoption. Early and frequent testing helps catch and fix bugs efficiently.
  • Next Steps: Support the latest Ansible versions, explore more efficient ways to define enterprise profiles.
  • Team: Tufan Geng, Frank, Qingbin, Wai, Xiang.

• WHIP (WebRTC-HTTP Ingest Protocol)

  • Project: Interoperability tests for WHIP (WebRTC-HTTP Ingest Protocol).
  • Goal: Test client-server communication using WHIP signaling (version 0.1) and underlying WebRTC exchanges with heterogeneous WebRTC stacks.
  • Accomplishments: Conducted interoperability tests among 4 server implementations and 6 client implementations. Most tests were successful, identifying and resolving several issues. Earlier tests helped inform fixes in WHIP version 0.1.
  • Learnings: Identified issues included assumptions about Location headers, mid usage in WebRTC (affecting Pion stack), hard-coded codec preferences (causing failed negotiations), self-signed certificate acceptance, and missing support for bearer tokens/CORS. Many issues led to fixes in client/server implementations.
  • Next Steps: Test authentication (bearer tokens), proper use of Location and Link headers, automatic STUN/TURN configuration, ICE restarts and related race conditions, and session cleanup.
  • Team: Lorenzo Miniero, Sergio Garcia Murillo, Tim Panton, Dan Jenkins, Cameron Elliott, Alberto Gonzalez-Stoic.

• Machine Readable Documents and Tools (Augmented Packet Header Diagrams)

  • Project: Regularizing packet header diagrams for automated parser code generation.
  • Goal: Develop tooling to automatically generate protocol parser code from standardized ASCII packet header diagrams in IETF drafts.
  • Accomplishments: Regularized the format of ASCII packet header diagrams and their descriptive lists in documents for parsability. Developed prototype tooling that generates Rust parser code from these diagrams. The format is adopted in the TCP BIS draft, allowing automatic TCP parser generation.
  • Learnings: Discussions focused on improving the "structured English phrases" for human readability and identifying mechanisms to mark structured text components to prevent accidental editing during RFC publication.
  • Next Steps: Add flexibility for generating parsers in more languages and improve robustness of the tooling to handle drafts that may not use the format.
  • Team: Stephen MacCuspin, Mark Pettigrew.

• Machine Readable Documents and Tools (Computer Specifying)

  • Project: Ensuring correctness of examples in RFCs through computer-aided specification.
  • Goal: Generate provably correct examples and ensure consistency with normative text by embedding executable code within specification documents.
  • Accomplishments: Extended asciidoc to embed and evaluate Idris code, inserting calculation results directly into the document (e.g., XML2RFC, HTML, PDF output). Developed an abnf library in Idris for defining and pretty-printing ABNF grammars. Demonstrated a method to generate a "proof" (type) that a string is syntactically correct according to an ABNF grammar (e.g., for S-expressions).
  • Learnings: ABNF alone is insufficient to describe all PDU constraints, necessitating higher-order logic and dependently typed languages like Idris to build proofs of correctness for generated examples.
  • Next Steps: Continue developing Idris libraries for common IETF draft problems. Release asciidoc extensions (version 15) with new features.
  • Team: Mark Pettigrew, Stephen MacCuspin, Colleen, Robert, Gene, Lucas.

• IoT Security

  • Project: Implementing and integrating various IoT security specifications.
  • Goal: Implement specifications from IETF IoT security working groups (CoAP, DTLS, SUIT, DICE), offer tutorials, and integrate different components.
  • Accomplishments: Held tutorials for new participants (slides and recordings available). Developed security extensions for TLS and mDTLS (e.g., BSAF crypto, connection IDs). Released Wireshark dissector code for some IoT protocols (already merged). Enhanced lightweight M2M client (Beckhammer) with security support. Deep dives into real-time operating systems for future integration. Identified several issues with SUIT and DICE specifications.
  • Learnings: Experience with embedded development is crucial. Tutorials were useful for onboarding. Identified open issues in current specs for working group discussion. Noted "online fatigue" as a challenge for sustained focus.
  • Next Steps: Continue implementation efforts, follow up on identified spec issues. Send hardware to participants (delayed due to bureaucracy).
  • Team: Hannes Tschofenig, various newcomers and returning participants.

• API Tax

  • Project: Developing a standard API for digital payments taxation.
  • Goal: Address the complexity of introducing taxes on digital payments, particularly for international transactions, by standardizing tax lookups and registration.
  • Accomplishments: Reviewed existing literature and initial design specifications. Developed a prototype in Go for looking up tax rates using ISO codes, exploring Stripe API as a basis.
  • Learnings: Existing solutions (e.g., Stripe API) predominantly cover North America and Europe, highlighting a gap for African and Asian countries. Considered relevant SDOs (EMVCO, PCI, OECD) and RFCs (RFC 5280) for security and transaction flows.
  • Next Steps: Develop a more complete API specification with examples and direct links to tax authorities for automated payments. Detail security and privacy aspects, potentially leveraging existing RFCs. Explore implementations in other languages.
  • Team: Benson Muite, Moses Ledwiko, Ali Hussein (feedback).

• Next Hackathon Logistics:

  • IETF 113 hackathon dates are set.
  • Format (in-person/virtual) is TBD; if virtual, it will run for the full week before IETF 113. If in-person, it will be held on the weekend before.
  • Hybrid participation will continue to be supported, with tools like Gather expected to be available.

Decisions and Action Items

• Decision: Presentations for the closing session were conducted using either Meetecho's pre-loaded slide sharing feature or individual screen sharing.
• Action Item: Hannes Tschofenig to upload his IoT Security presentation slides to the designated repository.
• Decision: The next IETF Hackathon will be held in conjunction with IETF 113.

Next Steps

• Individual Projects: Teams will continue development, analysis, and testing based on their identified "next steps" from their presentations.
• IETF 113 Hackathon: Participants should stay tuned for further announcements regarding the format (in-person, virtual, or hybrid) and specific details for the next hackathon. Gather is expected to remain available for hybrid participation regardless of the format.
• Sponsorship: Continued encouragement for "running code sponsorship" to support future hackathons.