98hackathon
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
98hackathon [2017/03/25 22:22] dbarthel [Technologies Included in Hackathon (more can be added)] |
98hackathon [2017/03/29 15:06] bortzmeyer Typo |
||
|---|---|---|---|
| Line 48: | Line 48: | ||
| * Code can be accessed from [[https://github.com/ietf-hackathon|IETF Hackathon Github]] or from links provided within project descriptions below. | * 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> | * Request to be added to IETF Github organization by sending your Github ID to Charles Eckel <eckelcu@cisco.com> | ||
| + | * [[https://isoc.app.box.com/v/IETFHackathon-201703|Hackathon Photos]] | ||
| ---- | ---- | ||
| Line 141: | Line 142: | ||
| * DBUS API and nss-resolv support for Stubby [[https://getdnsapi.net/presentations/stubby-nanog68.pdf]] | * DBUS API and nss-resolv support for Stubby [[https://getdnsapi.net/presentations/stubby-nanog68.pdf]] | ||
| * Asyncio support in getdns Python binding | * Asyncio support in getdns Python binding | ||
| - | * DNS-over-TLS service monitoring (e.g. [[https://www.monitoring-plugins.org/|Nagios]] plug-in). Using [[https://getdnsapi.net/|getdns]] seems a reasonable choice (or the [[https://miek.nl/2014/August/16/go-dns-package/|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) | + | * DNS-over-TLS service monitoring (e.g. [[https://www.monitoring-plugins.org/|Nagios]] plug-in). Using [[https://getdnsapi.net/|getdns]] seems a reasonable choice (or the [[https://miek.nl/2014/August/16/go-dns-package/|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) [[http://www.bortzmeyer.org/monitor-dns-over-tls.html|this article]] summarizes the result of this sub-project. |
| * TLS chain extension (draft-ietf-tls-dnssec-chain-extension-01) | * TLS chain extension (draft-ietf-tls-dnssec-chain-extension-01) | ||
| * IPv6-only prefix discovery for DNS64 (RFC 7050) | * IPv6-only prefix discovery for DNS64 (RFC 7050) | ||
| Line 152: | Line 153: | ||
| * Laurent Toutain <laurent.toutain@telecom-bretagne.eu> | * Laurent Toutain <laurent.toutain@telecom-bretagne.eu> | ||
| * Project(s) | * Project(s) | ||
| - | * the overall goal is to improve our Wireshark dissector for LoRaWAN to be used in the LPWA Working Group. | + | * 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 | * 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). | * 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). | ||
| Line 159: | Line 160: | ||
| * validation | * 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. | * 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'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. | + | * 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 | * 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. | * 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 | * open questions | ||
| - | * the LoRaWAN protocol is asymmetric: the uplink frame encoding is different from the downlink encoding. Do we need two separate dissectors, or can we convey an extra parameter to the single dissector? | ||
| * the LoRaWAN frames are authenticated and the payload is encrypted. | * 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 Authentication-By-Personalisation mode, the device and the servers are pre-provisioned with a network session key and an application session key. | ||
| Line 269: | Line 269: | ||
| ==== Remote participation ==== | ==== 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. | * 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. | ||
| - | * Jabber Room: hackathon@jabber.ietf.org | + | * [[xmpp:hackathon@jabber.ietf.org|Jabber room]] |
| + | * [[http://www.meetecho.com/ietf98/hackathon|Meetecho]]: Active and recorded Sunday from 14.00-16.00 | ||
| ==== IPR and Code Contribution Guideline ==== | ==== 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. | 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
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
