User Tools

Site Tools


99hackathon

This is an old revision of the document!


A PCRE internal error occured. This might be caused by a faulty plugin

==== IETF 99 Hackathon ==== The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. **When:** Saturday July 15, 2017 and Sunday July 16, 2017\\ **Where:** Hilton Prague, Room: [[https://datatracker.ietf.org/meeting/99/floor-plan?room=chez-louis#prague-hilton-mezzanine|Chez Louis]]\\ **Signup for the Hackathon here:** [[https://www.ietf.org/registration/ietf99/hackathonregistration.py|Hackathon Registration]]\\ **View the list of registered Hackathon attendees:** [[https://www.ietf.org/registration/ietf99/hackathonattendance.py?sortkey=3&login=%0A|Attendees]] Keep up to date by subscribing to [[https://www.ietf.org/mailman/listinfo/hackathon|https://www.ietf.org/mailman/listinfo/hackathon]]\\ The Hackathon is free to attend. ---------- ---- ==== Agenda ==== Saturday, July 15 08:00: Room open for setup of posters at tables by projects champions 09:00: Room open for all - Pastries and coffee provided 09:30: Hackathon kickoff 09:45: Form Teams 12:30: Lunch provided 15:30: Afternoon break - Snacks provided 19:00: Dinner provided 21:00: Room closes and is locked Sunday, July 16 09:00: Room opens - Pastries and coffee provided 12:30: Lunch provided 13:30: Hacking stops, prepare brief presentation of project 14:00: Project presentation to other participants and judges 15:00: Recap and suggestions for improvements 15:30: Awards presented, prizes given 16:00: Hackathon ends 17:00: Tear down complete For your planning purposes, be aware that we will also have: * Space reserved in the IETF Lounge throughout the week of IETF, July 17-21, for people to gather and collaborate on hackathon activities * A table at Bits-N-Bites on Thursday, July 20, for hackathon participants to share their projects with the IETF community at large ---- ==== Meeting Materials ==== * IETF Hackathon Prep Call - [[https://cisco.webex.com/ciscosales/lsr.php?RCID=c6b6d3fdabf845aab4667251cea50e45|Play recording (27 min 43 sec)]] Password: GpC6VeqP * Presentations can be uploaded and accessed from [[https://datatracker.ietf.org/group/hackathon/meetings/]] * Send presentations you want uploaded to Charles Eckel <eckelcu@cisco.com> * Code can be accessed from [[https://github.com/ietf-hackathon|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 Charles Eckel <eckelcu@cisco.com> * Hackathon Photos take and post to Twitter with hash tags #IETFHackathon #IETF99 ---- ==== Participant Preparation and Prerequisites ==== * Bring a laptop on which you are comfortable developing software * Some projects may require installing additional software * Familiarity with the technology area(s) in which you plan to participate will certainly help * Champions will have posters describing their project(s) and be available to answer questions at the start and throughout the hackathon * Your laptop is the default development platform for each technology * Anything else that is required will be provided, such as VMs you can install on our laptop or access from your laptop * Installing and becoming familiar with VirtualBox or something similar will help * Note to champions: if planning to make use of VMs, please bring on USB drives to make available to others as download times can be painful * Specific coding languages are called out for some of projects (e.g. Python, Java), but this is heavily dependent on the project(s) you choose * Wireless access to the IETF network will be provided, and from there to the outside world * Wired access to the IETF network is available by request only * Git/GitHub is commonly used for open source projects. Familiarizing yourself with it is recommended. * An online tutorial is available here: [[https://learninglabs.cisco.com/lab/git-intro/step/1|Git 100: Basics of the git version control system]] * Network programmability based on IETF standard protocols and models is relevant to many projects * [[https://learninglabs.cisco.com/lab/06-dmi-02-introducing-yang-data-modeling/step/1|Intro to YANG Data Modelling]] * [[https://learninglabs.cisco.com/lab/06-dmi-03-introducing-the-netconf-protocol/step/1|Intro to NETCONF Protocol]] * [[https://learninglabs.cisco.com/lab/04-introducing-the-restconf-protocol/step/1|Intro to RESTCONF Protocol]] * Champions for each technology are encouraged to share any other things they think would be helpful in preparation for the hackathon ==== Remote participation ==== * Participating in person is preferred, but we understand not everyone can travel. If you want to participate remotely, please contact the champion(s) for that project to determine how best to coordinate. * [[xmpp:hackathon@jabber.ietf.org|Jabber room]] * [[http://www.meetecho.com/ietf99/hackathon|Meetecho]]: Active and recorded Saturday from 09.30-10.00 and Sunday from 14.00-16.00 ==== IPR and Code Contribution Guideline ==== All hackathon participants are free to work on any code. The rules regarding that code are what each participant's organization and/or open source project 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. ---- ==== Technologies Included in Hackathon (more can be added) ==== **Authenticated Received Chain - ARC** * Champion(s) * Steven M Jones (smj overat dmarc dots org) * Background * Whatsit?: ARC conveys email authentication results across "indirect" (multi-hop, DKIM-breaking) mailflows. Independent of DMARC, but designed to address negative impacts of strong DMARC policies on mailing lists, other indirect mailflows. ARC includes signing features derived from DKIM. * ARC is a work item under the [[https://datatracker.ietf.org/wg/dmarc/|IETF DMARC Working Group]] * Specifications, etc: * [[https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/|I-D ARC Specification]] * [[https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/|I-D Usage Guide]] * [[https://tools.ietf.org/html/rfc7489|RFC7489 DMARC]] * [[https://tools.ietf.org/html/rfc7960|RFC7960 DMARC and Indirect Mailflows]] * [[https://tools.ietf.org/html/rfc6376|RFC6376 DKIM]] * [[https://tools.ietf.org/html/rfc7208|RFC7208 SPF]] * Implementations: * Python package: [[https://pypi.python.org/pypi/dkimpy/0.6.1|dkimpy]] * C/Milter package: [[https://github.com/mskucherawy/OpenARC|OpenARC]] * Test suite: [[https://github.com/ValiMail/arc_test_suite|arc_test_suite]] * Proprietary/Non-FOSS implementations by: * AOL * Google * MailerQ (Copernica) * Projects and Goals * Interoperability testing between implementations * Bugfixes for FOSS, proprietary implementations * Feedback to specification and other docs as needed * Reporting ARC Results: * Adding info to DMARC reports * Consuming info from DMARC reports * Perl implementation (**Top need**, volunteers welcome!) * Ruby implementation (volunteers welcome!) * Other suggestions? **HTTP error code 451** * Champions: Niels ten Oever (ARTICLE 19), dkg (ACLU), Joe Hall (CDT) * Background: HTTP error code 451 (RFC7725) is an error code to report legal obstacles for serving a webpage. During the hackathon we will focus on implementing and measuring this status code to make censorship more transparent. * Specifications, etc: [[https://tools.ietf.org/html/rfc7725|RFC7725]] * Code repo in [[https://github.com/451hackathon|github]] * Project and Goals: * a web-crawler to scan for HTTP error code 451 instances * a browser plugin which would report to the user, and optionally to the webcrawler, cases of HTTP error code 451 * a WordPress plugin which would enable site admins to block specific fields and serve 'blocked-by' info * create an implementation report ([[https://www.ietf.org/iesg/implementation-report.html]]) for RFC7725 * write human rights consideration for RFC7725 (in line with [[https://tools.ietf.org/html/draft-irtf-hrpc-research-12]]) **SDN Applications for management of microwave radio link via IETF YANG Data Model** * Champion(s) * Ye Min (infrastructure and use cases) * Jonas Ahlberg (use cases) * Background * A YANG Data Model for management of microwave radio link is under development, [[https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-00|draft-ietf-ccamp-mw-yang-00]] * 1st individual draft submitted – April 4, 2016 * IETF Design Team established June 1, 2016 * A third version of the model under preparation * Model needs to be validated in practice - IETF Hackathon is one way to get hands-on experience * Project(s) * Development of applications for management of microwave nodes * Energy Efficiency: to save power consumption when traffic is low * Dynamic frequency control: to control the interference * ... * Infrastructure * Applications developed on top of an ODL-based SDN controller, via RESTCONF interfaces * ODL controller simulates microwave nodes using an embedded YANG model, [[https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-00|draft-ietf-ccamp-mw-yang-00]] **DNS, DNSSEC, DNS Privacy** * Champion(s) * Sara Dickinson sara@sinodun.com * Allison Mankin allison.mankin@gmail.com * Benno Overeinder benno@nlnetlabs.nl * Melinda Shore melinda.shore@nomountain.net * Jan Včelák jvcelak@ns1.com * Petr Špaček petr.spacek@nic.cz * Project(s) * Implementation of the BULK resource record in an authoritative name server. BULK allows generation of records on-the-fly by the authoritative name server. is described in draft-woodworth-bulk-rr. There is currently no published implementation (a BIND implementation seems to be under work, but nothing was released). I (Stéphane Bortzmeyer) would like to try to implement it in NSD, to see if it's realistic. * Implementation of C-DNS, the DNS-specialized packet capture format (to replace pcap in some cases). It is described in draft-ietf-dnsop-dns-capture-format. It claims to be simple to implement. Already one [[https://github.com/dns-stats/compactor|implementation]]. I (Stéphane Bortzmeyer) would like to develop a reader or a writer in Go, to test interoperability with the first implementation. Possible approach for the writer: use dnstap, and the dnstap listener would produce C-DNS. Note there is [[https://github.com/dnstap/golang-dnstap|a dnstap listener written in Go]], which can output text and YAML. Other approach for the writer: a pcap2cdns program. * Discussion/design session on how DNS implementations can/should manage the root KSK rollover (considering both 5011 and alternative mechanisms). For example, this is non-trivial for a library like getdns. * DBUS API and nss-resolv support for Stubby https://www.nanog.org/sites/default/files/3_stubby-nanog68.pdf * Ed25519 (RFC 8080) RRSIG * RFC 5011 compliance testing using [[https://gitlab.labs.nic.cz/knot/deckard/blob/master/README.rst|Deckard]] - reusable, lighting fast test based on [[https://github.com/wolfcw/libfaketime|libfaketime]] **YANG/NETCONF/RESTCONF** * Champion(s) * Benoit Claise * Project(s) * yangcatalog.org: Joe Clarke, Benoit Claise * Implement the YANG module report per IETF WG, out of the yangcatalog.org : Qin Wu, Dapeng Liu * Improve YANG model monitoring tools at http://www.claise.be/ : Benoit Claise * Review and resolve BBF YANG errors shown by Benoit's tools (especially yangdump-pro) : William Lupton (partly Saturday, full Sunday) * yanglint (libyang, libnetconf2, Netopeer2, sysrepo) : Radek Krejci * yuma123 (API, netconfd, yangcli) : Vladimir Vassilev * Update backend tools used by yangvalidator.com to handle multiple drafts/YANG models: Mahesh Jethanandani * Fix MEF model dependencies: Mahesh Jethanandani * MEF models and related metadata in the yangcatalog: Mahesh Jethanandani * Validate the yangcatalog.org APIs with the BBF metadata: William Lupton * yangcatalog code development: Miroslav Kovac * YANG module tree type conversion: Rob Wilton (Sunday) * Generate an IETF draft from a YANG module (in support of draft-claise-semver-00): Richard Barnes (mainly Sunday) * Create pyang module-catalog plugin to generate draft-clacla-netmod-model-catalog compliant JSON : William Lupton * Regex tool and regex GUI: Radek and Pieter Lewyllie * Private YANG models: Kent Watsen **SeDHCPv6** - CANCELLED! * DHC WG needs to regroup on this work to see what next steps are as several issues were raised with draft and the document has not been updated. Perhaps a requirements document will be needed to clarify what security is desired. See https://www.ietf.org/mail-archive/web/dhcwg/current/msg18194.html as to a meeting that we will try to hold on Sunday afternoon (14:00). * Champion(s): TBD * Project: [[https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-21|draft-ietf-dhc-sedhcpv6-21]] defines Secure DHCPv6, an encrypted and possibly authenticated version of DHCPv6 protocol. The goal of this hackathon is to extend existing DHCPv6 implementations and attempt inter-operability testing for encryption and authentication. We hope to have the following implementations at various stages of maturity: * WIDE - A client code is available from earlier hackathon, back in 2015: https://github.com/jinmei/wide-dhcpv6/tree/sedhcpv6. Contact person for this earlier effort: Jinmei Tatuya. * Cisco CNR - http://www.cisco.com/c/en/us/products/cloud-systems-management/network-registrar/index.html. Contact person for this implementation: Bernie Volz * Kea - A server code is available form earlier hackathon, back in 2015. https://github.com/isc-projects/kea/tree/sedhcpv6a. Contact persons for this implementation: Francis Dupont, Tomek Mrugalski * Other implementations are more than welcome. * Wireshark: It seems plausible that some of the effort during the hackathon will be spent on extending wireshark (https://www.wireshark.org/) to be able to parse the encrypted traffic, assuming necessary security details (keys, certs) are provided. This work hasn't started yet. Volunteers are more than welcome. Note that although there is existing code for some implementations, it is based on a very old -08 draft. The recent -21 draft has changed substantially. In particular, mandatory encryption has been added that was not present in the old -08 draft. ** SACM ** * Champions * Adam Montville * David Waltermire * Project: SACM has defined a vulnerability assessment scenario (see https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario), and this project seeks to *prototype* one or two paths through that scenario for the express purpose of informing our architectural components, component interfaces, and the SACM information model. * Explicit goals and a user story are provided here: see https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentHackathon * We ultimately seek to assess endpoint state using a number of state collection mechanisms * For this "spike" we are ignoring certain facets of a full solution (i.e. endpoint/service discovery) We have some folks willing to contribute a variety of components to the effort, and we will be working together before the hackathon takes place, with the hope that face-to-face time will be used for figuring the last details rather than kicking off the effort. **RIOT** * Champion(s) * Peter Kietzmann * Martine Lenders * Cenk Gündoğan * Christopher Scherb (CCN-lite) * Claudio Marxer (CCN-lite) * Project(s) * TSCH/OpenWSN fresh port to RIOT * Enhancement of RIOT network stack GNRC * 6LoWPAN mesh-under-support * Various updates from newer RFCs (e.g.7973 and 8025) * Energy optimization w/ focus on radio device control * ICN in IoT: provide an adaptation layer for CCN/NDN to low power lossy networks * header and/or name compression * fragmentation **OpenWSN** * Champion(s) * Tengfei Chang * Peter Kietzmann * Remy Leone * Jonathan Munoz * Malisa Vucinic * Xavi Vilajosana * Thomas Watteyne * Project(s) * RIOT support * F-Interop * 6TiSCH Wireshark Dissector * ARMOUR Secure Join * 6LoWPAN fragmentation **SCHC implementation and test** * Champion(s) * Laurent Toutain * Dominique Barthel dominique DOT barthel AT orange DOT com * Project(s) * SCHC (Static Context Header Compression) is a header compression mechanism for CoAP/UDP/IPv6 dedicated to LPWAN networks defined in [[https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05]]. Implementations exist. One goal is to test their interoperability, another goal is to help developers design their own implementation. **QUIC** * Champion(s) * Patrick McManus pmcmanus@mozilla.com * Project(s) * QUIC First Implementation Draft Interop * See https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft * -04 drafts **Interface to Network Security Functions (I2NSF) Framework** * Champion(s) * Jaehoon Paul Jeong (pauljeong@skku.edu) * Sangwon Hyun (swhyun77@skku.edu) * Project(s) * I2NSF Framework for provisioning Network Security Functions (NSF) * Consumer-Facing Interface via RESTCONF/YANG * NSF-Facing Interface via NETCONF/YANG * Network Security Functions * Firewall using SDN and Suricata * Deep Packet Inspection (DPI) using Suricata * Advanced Functions * NSF-triggered Traffic Steering using SFC * YANG Data Modeling for NSF Monitoring * Specifications: * [[https://tools.ietf.org/html/draft-ietf-i2nsf-framework-05]] * [[https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-16]] * [[https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-01]] * [[https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-01]] * [[https://tools.ietf.org/html/draft-xibassnez-i2nsf-capability-01]] * [[https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-01]] * [[https://tools.ietf.org/html/draft-hares-i2nsf-capability-data-model-01]] * [[https://tools.ietf.org/html/draft-jeong-i2nsf-sdn-security-services-05]] * [[https://tools.ietf.org/html/draft-hyun-i2nsf-nsf-triggered-steering-02]] * [[https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-im-01]] * [[https://tools.ietf.org/html/draft-hyun-i2nsf-registration-interface-dm-00]] * [[https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-03]] * Implementation: * Github Page: [[https://github.com/kimjinyong/i2nsf-framework]] * Suricata (Oepn Source IDS/IPS/NSM Engine): [[https://suricata-ids.org/]] **Loss-Latency tradeoff** * Champion(s) * Thomas Fossati (thomas.fossati@nokia.com) * Background * We came out of the ACCORD BoF with the action to go and get more data to inform the discussion on implicit/explicit cooperation between endpoints and the network. This project aims exactly at that: gathering the missing data that can resume that conversation :-) * Specifications * https://tools.ietf.org/html/draft-you-tsvwg-latency-loss-tradeoff-00 * Code repo * https://github.com/mami-project/one-bit-experiment/tree/master/docker * Project and Goals * Project goal is to measure the effects of two different kinds of queueing disciplines (LLT and AQM) when applied to "interesting" traffic mixes. The traffic mixes in question comprise low-latency and greedy flows competing under near-congestion. * Concrete things to work on, in order of importance: * Add an AQM setup; * Refine traffic mixes and measurement harness; * Measure LoLa vs AQM vs baseline; * Polish the LLT implementation. **ACME STAR** * Champions * Thomas Fossati (thomas.fossati@nokia.com) * Integrate ACME-STAR with STAR-request * ACME-STAR [https://tools.ietf.org/html/draft-ietf-acme-star-00] is an ACME extension that allows automatic renewal of short-term certificates * STAR-request [https://tools.ietf.org/html/draft-sheffer-acme-star-request-01] is a protocol for asking a domain name holder a rolling set of short term certificates for a keypair that is held by a third party with a domain holder's name. Typically, the use case is that of a CDN edge cache that needs to answer HTTPS requests for URLs that have the domain name holder's authority. * Code repo * https://github.com/mami-project/lurk * https://github.com/letsencrypt/boulder * Project Goals * implement the two specs as far as needed to implement an "happy" end-to-end scenario **TCPINC** * Champion * Kyle Rose * Projects and Goals * Tcpcrypt P-256 for the Linux kernel * Building off work at the IETF 98 hackathon to implement TCP-ENO negotiation in the Linux TCP stack, I'll be working to implement the tcpcrypt protocol using P-256 ECDH * Goal is to achieve interoperability for an opportunistically-encrypted TCP stream with the reference implementation from tcpcrypt.org * Other implementors are welcome to join me for coffee and coding * Code repo * https://github.com/squarooticus/tcpinc-linux **SCTP** * Champion(s) * Michael Tüxen (tuexen@fh-muenster.de) * Randall Stewart (randall@lakerest.net) * Project(s) * Improve the FreeBSD SCTP implementation, especially support for the SCTP I-DATA extension specified in https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-11 and used by WebRTC. The source code is available from https://github.com/sctplab. **NEAT / TAPS** * Champion(s) * Michael Tüxen (tuexen@fh-muenster.de) * Felix Weinrank (weinrank@fh-muenster.de) * Project(s) * The NEAT project (https://www.neat-project.org) develops a networking library available at https://github.com/neat-project. The goal is to improve this library, port applications to it and extend the WebRTC support of the NEAT library. **DOTS** * Champion(s) * Kaname Nishizuka * Koji Okada * Project(s) * DDoS Open Threat Signaling (DOTS). * The aim of DOTS is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. * We develop PoC code of the dots protocol based on the latest specifications. * The goal is to improve the code and demonstrate some of the user scenarios. * In addition to testing whether the specification of the latest drafts works well, we'd like to test interoperability with other software if there is an opportunity. * Specifications * https://tools.ietf.org/html/draft-ietf-dots-signal-channel-02 * https://tools.ietf.org/html/draft-ietf-dots-data-channel-02 * Implementation * The code will be available at [will be opened soon] **Multiple Provisioning Domains (mPvD) and Captive Portal detection** * Champion(s) * Pierre Pfister * Project(s) * Multiple Provisioning Domains (mPvD) and Captive Portal detection. * The proposed project consists in implementing captive portal detection using the IPv6 Router Advertisement PvD option defined in draft-bruneau-intarea-provisioning-domains-01. The captive portal URL could be included in the PvD addition data. This work will be based on existing open-source implementation of the mPvD draft. * Other topics related to mPvD or captive portals are welcome as well. * Specifications * https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01 * https://tools.ietf.org/html/draft-larose-capport-architecture-00 * Implementation * Some mPvD code is available here: https://github.com/IPv6-mPvD **COSE in the network: Secure Wake-on-Radio (SWORN)** * Champions * Olaf Bergmann * Benjamin Piepiora * Background * COSE is the CBOR object signing and encryption specification, RFC 8152-to-be. * COSE is mostly thought as a component for application protocols, but it can be used in the network as well. * Wake-on-Radio can save a lot of power for battery-operated devices by having them wake up and consume power only when there is actually something to do. But Wake-on-Radio provides a too easy DoS vector for a battery depletion attack. Secure Wake-on-Radio Nudging (SWORN) enables a last-hop router to find out if the correspondent node was authorized to wake up the device with a packet. * Project * Implement SWORN in an actual IoT scenario with Wake-on-Radio * Demonstrate the power savings achievable * Demonstrate the workflow for getting a correspondent node authorized * Cooperate with other COSE connoisseurs and IoT power savers * Specification: https://tools.ietf.org/html/draft-bormann-t2trg-sworn **SysRepo - Segment Routing v6** * Champions * Richard Kosegi * Boris Pilka * Martin Pilka * Alex Tokar * Project * NETCONF management of Segment Routing over IPv6 (SRv6) on OpenWRT router * The goal is to make POC of configuring explicit path consisting of SRv6 segments on OpenWRT router (TL-WR1043ND) via NETCONF. There is support of SRv6 in Linux kernel since 4.10, so let's make use of it. * Implementation: * OpenWRT:[[https://github.com/openwrt]] * SysRepo:[[https://github.com/sysrepo]] * Netopeer:[[https://github.com/CESNET/Netopeer2]] **MILE** * Champion(s) * Takeshi Takahashi * Mio Suzuki * Project(s) * Managed Incident Lightweight Exchange (MILE). * The aim of MILE is to develop a set of standards and protocols for efficiently exchanging incident-related information among parties in order to prepare and/or mitigate assorted cyber incidents. * We develop PoCs and tools for improve the usability of MILE specifications. For instance, the following tools will be developed before and during the Hachathon. * develop a converter between IODEF and STIX * develop PoC code, which generates an IODEFv2 document from a darknet monitoring system * Specifications * https://datatracker.ietf.org/doc/rfc7970/ * https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/ * Implementation * The code will be available at [will be opened soon] ** Secure IoT bootstrapping for Noobs with EAP-NOOB ** * Champion(s) * Mohit Sethi (mohit.m.sethi@ericsson.com) * Shiva Prasad TP * Tuomas Aura (tuomas.aura@aalto.fi) * Raghavendra Mudugodu * Project(s) * Implementing EAP-NOOB with open source wpa_supplicant and hostapd: https://tools.ietf.org/html/draft-aura-eap-noob-02 * EAP-NOOB is an EAP method where the authentication is based on a user-assisted out-of-band (OOB) channel between the server and peer. * It is intended as a generic bootstrapping solution for Internet-of-Things devices which have no pre-configured authentication credentials and which are not yet registered on the authentication server. Consider devices you just bought or borrowed. * Working code on github: https://github.com/tuomaura/eap-noob * During the hackathon we plan to work on the following: * Various bug fixes * Testing improved cryptoagility and error handling version -02 * Fuzz testing * Testing the code with new kinds of IoT devices and OOB channels such as audio * User experience in real deployment * Try it out sessions * We are happy to have your contribution. It could be simple feedback on some missing features or more detailed protocol improvements. * Specifications * https://tools.ietf.org/html/draft-aura-eap-noob-02 * Implementation * https://github.com/tuomaura/eap-noob **MPTCP** * Champions * Benjamin Hesmans (benjamin.hesmans@uclouvain.be) * Fabien Duchêne (fabien.duchene@uclouvain.be) * Quentin De Coninck (quentin.deconinck@uclouvain.be) * Projects * MPTCP socket API usage and HTTP headers (kore, curl ...) * Experimental options for MPTCP (rfc6824bis, section 3.7) * ADD_ADDR reliability * iOS tests (we will bring an iPhone that has iOS 11 beta) * Linux implementation of RFC6824bis * Specifications * https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-08 * Implementation * https://github.com/multipath-tcp/mptcp **Multicast over SPRING** * Champions: * Jake Holland * John Brzozowski * Project: * Experimenting with IPv6 Multicast transport over Segment Routing, using AMT for membership signaling. * Specifications: * https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 * https://tools.ietf.org/html/rfc7450 * Implementation: * https://github.com/GrumpyOldTroll/amt * https://github.com/GrumpyOldTroll/amt-openwrt ---- Don’t see anything that interests you? Feel free to add your preferred technology 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 technology, we strongly suggest that you send email to hackathon@ietf.org to let others know. You may generate interest in your technology, 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-Technology-Name** * Champion(s) * tbd * Project(s) * tbd To **request a wiki account**, please click on the //**login**// button on the top right corner of the page, and choose //**register**//. If you need a new password please click on the //**login button**// on the top right corner of the page and choose //**Send new password**//.

99hackathon.1500070540.txt.gz · Last modified: 2017/07/14 22:15 by bclaise