User Tools

Site Tools


98hackathon

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
98hackathon [2017/03/23 02:23]
caroldavids
98hackathon [2017/04/12 20:24] (current)
eckelcu_cisco.com [Meeting Materials]
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]]
 +     * [[https://​communities.cisco.com/​community/​developer/​opensource/​blog/​2017/​04/​12/​ietf-98-hackathon-in-chicago-improves-internet-through-running-code|Summary Blogpost]]
  
 ---- ----
Line 57: Line 59:
      * Project(s)      * Project(s)
        * yangcatalog.org:​ Joe Clarke, Benoit Claise, Einar Nilsen-Nygaard (remote, tentative)        * 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        * 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        * 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čí        * yanglint in http://​yangvalidator.org/:​ Radek Krejčí
 +       * SDO plugins in http://​yangvalidator.com : Mahesh Jethanandani
        * L3SM Yang in ONOS: Gaurav Agarwal        * L3SM Yang in ONOS: Gaurav Agarwal
        * RFC 6470,7895 and 7950 implementations for yuma123 and new 2.10 release and Debian package: Vladimir Vassilev        * 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
  
  
Line 95: Line 100:
        * Nick Sullivan <​nick@cloudflare.com>​        * Nick Sullivan <​nick@cloudflare.com>​
      * Project(s)      * Project(s)
-       * draft-19 +       * draft-19 - https://​tools.ietf.org/​html/​draft-ietf-tls-tls13-19 
-       * OCSP + SCT cross-compatibility+       * OCSP + SCT cross-compatibility ​- https://​tlswg.github.io/​tls13-spec/#​certificate
        * 0-RTT + HTTP/2        * 0-RTT + HTTP/2
-       * Delegated Credentials +       * Delegated Credentials ​- https://​tools.ietf.org/​html/​draft-rescorla-tls-subcerts-01 
-       * Exported Authenticators+       * Exported Authenticators ​- https://​tools.ietf.org/​html/​draft-sullivan-tls-exported-authenticator-01
  
 ** NETVC ** ** NETVC **
Line 138: Line 143:
      * 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)
      * Others welcome ​      * Others welcome ​
  
-**I2RS RIB ** 
-     * Champions(s)  ​ 
-     * Susan Hares  
-     * Project(s) 
-       * GateD implementation of I2RS RIB  
-       * GateD implementation of Topology ​ 
  
 **LoRaWAN Wireshark dissector** **LoRaWAN Wireshark dissector**
Line 155: Line 154:
        * Laurent Toutain <​laurent.toutain@telecom-bretagne.eu>​        * Laurent Toutain <​laurent.toutain@telecom-bretagne.eu>​
      * Project(s)      * Project(s)
-       * improve our Wireshark dissector for LoRaWAN to be used in the LPWA Working Group+       ​* ​the overall goal is to improve our Wireshark dissector for LoRaWANto 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). 
-       * the current code can be found at https://github.com/ltn22 +       ​* ​development 
-       * we'll add dissection of the various options of the LoRaWAN frame headers, as well as the various MAC commands (which 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)
-       * the LoRaWAN frames are authenticated and the payload is encrypted. ​In the Over-The-Air-Authentication mode, session keys are derived from a preshared ​key and a nounce. ​We'll discuss ways by which our dissector could learn these keys to be able to MIC-check and decrypt the frames. ​Prior experience from contributors with other protocol ​dissectors would be very valuable. +           * the current C-code source can be found at https://​github.com/​ltn22,​ which also includes instructions for recompiling Wireshark with the custom dissector 
-       * we currently don't sniff the LoRaWAN frames off-the-air,​ but transport them inside another proprietary protocol: we'll provide such pcap files. +           * the LoRaWAN 1.0.2 specification can be obtained from http://​www.lora-alliance.org/​For-Developers/​LoRaWANDevelopers
-       * we'll be able to run live experiments (remotely) on the LoRaWAN commercial network in France. ​  +       * 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**  ​**Interface to Network Security Functions (I2NSF) Framework**
Line 221: Line 231:
        * Alan Johnston <​alan.b.johnston@gmail.com>,​ IIT        * Alan Johnston <​alan.b.johnston@gmail.com>,​ IIT
     * Project(s)     * Project(s)
-       * WebRTC emergency services with indoor ​location provided using the pidf-lo xml format +       * WebRTC emergency services with location provided using the pidf-lo xml format ​from beacons or from browser 
-       * Includes WebRTC and SIP callers, WebRTC PSAP (Public Service Answering Point) call taker, and indoor location provided by BlueTooth LE beacons and a Location Server/​Database+       * Includes WebRTC and SIP callers, WebRTC PSAP (Public Service Answering Point) call taker, and indoor location provided by BlueTooth LE beacons and a Location Server/​Database ​or W3C Geolocation APIs
        * Based on https://​tools.ietf.org/​html/​draft-ietf-rtcweb-overview and https://​tools.ietf.org/​html/​draft-aboba-rtcweb-ecrit and https://​tools.ietf.org/​html/​draft-marshall-ecrit-indoor-location        * Based on https://​tools.ietf.org/​html/​draft-ietf-rtcweb-overview and https://​tools.ietf.org/​html/​draft-aboba-rtcweb-ecrit and https://​tools.ietf.org/​html/​draft-marshall-ecrit-indoor-location
        * Using open source components such as NGINX, Kamailio, and Node.js and cloud APIs Agora.io        * Using open source components such as NGINX, Kamailio, and Node.js and cloud APIs Agora.io
        * Handle end-to-end WebRTC and SIP-to-WebRTC emergency calls with location information        * Handle end-to-end WebRTC and SIP-to-WebRTC emergency calls with location information
-       * github ​URL TBD+       ​* ​Repository https://github.com/​IETF-Hackathon/​webrtc-e911-psap
  
  
Line 260: Line 270:
 ==== 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.1490235818.txt.gz · Last modified: 2017/03/23 02:23 by caroldavids