User Tools

Site Tools


98hackathon

IETF 98 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 March 25, 2017 and Sunday March 26, 2017
Where: Swissotel Chicago, Vevey1/2
Signup for the Hackathon here: Hackathon Registration
View the list of registered Hackathon attendees: Attendees

Keep up to date by subscribing to https://www.ietf.org/mailman/listinfo/hackathon
The Hackathon is free to attend.



Agenda

  Saturday, March 25
      08:00: Room open for setup by projects champions    
      09:00: Room open for all - Pastries and coffee provided
      09:00: Posters of all technologies on display
      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, March 26
      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, March 27-31, for people to gather and collaborate on hackathon activities
  • A table at Bits-N-Bites on Thursday, March 30, for hackathon participants to share their projects with the IETF community at large

Meeting Materials


Technologies Included in Hackathon (more can be added)

YANG/NETCONF/RESTCONF

  • Champion(s)
    • Benoit Claise
  • Project(s)
    • yangcatalog.org: Joe Clarke, Benoit Claise, Einar Nilsen-Nygaard (remote, tentative)
    • BBF YANG modules in the catalog: William Lupton, Benoit Claise
    • improve YANG model monitoring tools at http://www.claise.be/ : Benoit Claise
    • pyang plugin - mapping combined config/state YANG models to split config/state models (IETF and/or OpenConfig structure): Rob Wilton
    • yanglint in http://yangvalidator.org/: Radek Krejčí
    • SDO plugins in http://yangvalidator.com : Mahesh Jethanandani
    • L3SM Yang in ONOS: Gaurav Agarwal
    • RFC 6470,7895 and 7950 implementations for yuma123 and new 2.10 release and Debian package: Vladimir Vassilev
    • yangexplorer and YDK - integrate YDK with yangexplorer to generate python code for attributes/actions selected in yangexplorer : Mahesh Jethanandani

Universal Acceptance (see www.uasg.tech for background on Universal Acceptance)

  • Champion(s)
  • Project(s)
    • Identify the applications that the IETF uses that are UA relevant – that is that they deal with a domain name, including domain names in email addresses.
    • Prioritise the application for ease of remedy or maximum benefit – ideally one and the same.
    • Review the code, including code libraries. If newer libraries are available that include UA Ready routines, then make the upgrade and deploy the UA ready routines.
    • Where routines are not available in the existing or more current library, then make the relevant code changes to make the application UA Ready.
    • Consider updating the underlying library with UA ready routines.
    • EAI - UTF8 Support in IMAP (RFC6855)

ANIMA

  • Champion(s)
  • Project(s)
    • Interop testing of Autonomic Networking Infrastructure components - try to get prototypes to work together.
    • Bootstrap testing of: voucher creation, exchange and validation, pledge/Join Registrar interaction, Join Proxy/Join Registrar discovery, Pledge/Join Proxy Discovery

DTLS

  • Champion
  • Project: I would like to spend one day on the DTLS Transport-Agnostic Security Association Extension (draft-mavrogiannopoulos-tls-cid-00) and record layer optimizations. This is useful for version 1.2 and 1.3. On the second day I would like to focus on DTLS 1.3 (draft-rescorla-tls-dtls13), specifically the epoch handling and the ACK message handling.

TLS 1.3

NETVC

COSE/JOSE

  • Champion(s)
  • Project(s)
    • Test vectors for JWT/CWT documents
    • OSCOAP Interop Testing
    • EDHOC development

DNS/DPRIVE/DNSSEC/DANE

  • Champion(s)
  • Projects
    • 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.
    • DNS Client RPZ-like filter (Create GUI to control a local resolver and configuration and filter DNS traffic at the client. Useful when using an un-filtered/un-censored recursive e.g. a DNS Privacy service.)
    • DBUS API and nss-resolv support for Stubby https://getdnsapi.net/presentations/stubby-nanog68.pdf
    • Asyncio support in getdns Python binding
    • DNS-over-TLS service monitoring (e.g. Nagios plug-in). Using getdns seems a reasonable choice (or the Go DNS librray since Go has a good TLS package?). Must be able to specify: expiration date for the cert (like the check_http plugin), the qname, qtype, the pinned key… Bonus: being able to test the TLS configuration (no weak cipher, etc) this article summarizes the result of this sub-project.
    • TLS chain extension (draft-ietf-tls-dnssec-chain-extension-01)
    • IPv6-only prefix discovery for DNS64 (RFC 7050)
    • Others welcome

LoRaWAN Wireshark dissector

  • Champion(s)
  • Project(s)
    • the overall goal is to improve our Wireshark dissector for LoRaWAN, to be used at the LPWA Working Group as when we experiment with extreme IPv6 header compression over low-power wide-area links (https://tools.ietf.org/wg/lpwan/draft-ietf-lpwan-ipv6-static-context-hc).
    • development
      • as a first step, we'll add dissection of the various options of the LoRaWAN frame headers, as well as the various MAC commands (which can appear either in the header options list or as a payload).
      • the current C-code source can be found at https://github.com/ltn22, which also includes instructions for recompiling Wireshark with the custom dissector
      • the LoRaWAN 1.0.2 specification can be obtained from http://www.lora-alliance.org/For-Developers/LoRaWANDevelopers.
    • validation
      • in short: we'll provide pre-baked pcap files; we'll also be able to generate pcap files as needed, from a live LoRaWAN network.
      • caveat: per current setting, we don't sniff the LoRaWAN frames straight off-the-air, but transport them inside another proprietary protocol that carries meta-data along with the LoRaWAN frames (such as received signal strength, frequency, modulation, etc.). That's the way the dissector is made to work with us right now. We'll provide the corresponding pcap files. If you have pcap files with raw LoRaWAN frames (or even an actual sniffing device that you want to bring to the meeting), we'll make sure that the dissector accommodates your case.
      • caveat2: in order to run Wireshark on our pcap files, you'll need our proprietary protocol dissector in addition to LoRaWAN's. It can be found at https://github.com/Orange-OpenSource/sensorlab-dissector
      • we'll be able to run live experiments (remotely) on a LoRaWAN commercial network in France (one node in the city of Grenoble and one in the city of Rennes) to capture the traces we need to debug the dissector.
    • open questions
      • the LoRaWAN frames are authenticated and the payload is encrypted.
        • in the Authentication-By-Personalisation mode, the device and the servers are pre-provisioned with a network session key and an application session key.
        • in the Over-The-Air-Authentication mode, both session keys are derived from a pre-shared root key and a nounce provided by the network server.
      • in either case, the dissector needs to know the session keys in order to be able to display the decrypted content.
      • we'll discuss ways by which our dissector could learn these keys in order to be able to MIC-check and decrypt the frames. Both ABP and OTAA modes will be discussed.
      • prior experience from contributors with dissectors for other authenticated/encrypted protocols would be extremely valuable.

Interface to Network Security Functions (I2NSF) Framework

Captive Portal

AMT/multicast

  • Champion(s)
  • Project(s)
    • Port amtrelayd to at least one wifi router under OpenWRT or similar
    • Add and test IPv6 support
    • Conformance tests vs. RFC 7450
    • Interop testing with other AMT implementations (Cisco, Juniper, etc.)
    • Stream some video through the relay
    • Make a libamtgw library for embedding AMT gateway functionality in client apps
    • Anything else that might make this technology easier to adopt and deploy

tcpinc: TCP-ENO, tcpcrypt

  • Champion(s)
  • Project(s)
    • Working on a Linux kernel implementation of ENO
    • I welcome anyone else's help or independent contribution

WebRTC

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.


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.
  • 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.
  • Meetecho: Active and recorded 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.

98hackathon.txt · Last modified: 2017/04/12 20:24 by eckelcu_cisco.com