Notes - IRTFOPEN Meeting, 16 Nov 2017 Welcome - Allison Mankin, Chair of IRTF -Note Well - Shown as adapted by IRTF - as IRTF follows IETF on this -Anti-harassment policy part of this and notes Ombuds role. People with need for the Ombuds from IRTF should preferably talk to Linda Klieforth or Pete Resnick as needed -Photography - due to prize distribution - note that you can opt out of being photographed and should mention to Allison or to the photographers Agenda (slides) -Update on IRTF --Mission - reviews role re applied research and IRSG role -RG Differences --Organized differently - can be creative in how work is done. Goal is impactful work. No requirement to have a strict process. Groups can have meetings co-located with other orgs and meetings. Some RG were closed in the past, none now. All groups are open. Caveat if held elsewhere, we expect the meeting to be announced on mailing lists. RG chairs, this means filing as an Interim Meeting. --Outputs can be RFC or code, hackathon, pubs in journals/conferences, agenda in scholarly body, other. If you have suggestions for other methods - creativity/experiment - okay --RG’s do not produce standards track docs info/experimental track docs. Some groups aim to solve a problem and can then take it to an IETF WG [incubator]. Examples of this in the past include NMRG -> ANIMA, RMRG ->RMT, DTNRG -> DTN -IRTF.org all wiki info and other data here -Chair IRTF-Chair@irtf.org -{typing cats insert ;) -RG’s Origins - open to new things and people, originate more freely and encourage creation of groups- can exist as a proposed RG “state”. Get to 3 meetings and chair reviews for the PROPOSED RG and community. -Slide of all RGs - all RGs met formally, except for one that met informally (Decentralised InterNet) --Chair notes that she is interested in soliciting a Privacy RG ---HRPC - Sandra on law, policy, politics, history of same; Avri D - one RFC out and other things in the works - good time to get involved -Q’s -Q/Mat why not moving so quickly for DINRG. A/Melinda - start-up mode and need more active participation - thinking of London and also an interim collocated with NDSS -IRTF Chair will put out a report on Discuss List about observations of RGs and meetings --PAN will meet right after lunch (today) - working on scope and meeting can help and define - focus on path awareness --Chair notes that she participates in scheduling and tries to help avoid conflicts with other meetings - but notes at mercy of time. Have talked about x-group interaction with docs and work. May have parallel work co-sponsored by two groups - noting, that the IRTF has the freedom to do that ---RG Chairs are members of the IRSG with some at-large members as well. Notes relationship with transport area as a special one. --Chair Notes 2 ANR*, the ANRP and the ANRW. ANRP is best-paper prize for applied networking and applied security. Not strict about which year the previously published work was in though should be in the last few years. Speakers nominated (see slides). 6 Awardees, monetary prize, travel money. ---ANRP’s Origin. It originated in a bright idea from Mat Ford of ISOC and the previous IRTF Chair, Lars Eggert. ISOC funds and some other sponsors help. Thanks to ISOC and Comcast and for this round of sponsorship. ---almost 60 submissions for this ANRP round, deadline was 5 Nov. Peer review committee from academia and industry - see https://irtf.org/anrp/2018 ---2 ANR things - some confusion between R and W - ----ANRP - Prize for already published papers with presentations at 3 IETFs ----ANRW - new papers, workshop TPC, presentation at the workshop at the Summer IETF ---Follow on Twitter @inretafo OPEN MIC --Pechakucha host (Aaron): there is idea under discussion to also create lightning talks to focus on new ideas during IETF that does not conflict with IETF or IRTF - looking for ideas - talk to Aaron or Alia. ANRP Prize Winners (slides) Chair - introduces First Awardee Paul Emmerich - introducing high-speed packet generator project. PhD student at Tech Univ Munich since 2014 -MoonGen: A Fast and Flexible Packet Generator (Slides) --Describes what it is and how it can be applied --Thesis is testing diff network devices, interest emerged out of his work on Masters; team at University looking at a broad range of issues (traffic measurement, SDN, security, privacy, P2P nets, IOT, Perf anal/modeling). --He focuses on Perf Analysis and Modeling - packet processing becomes more complex/same with networking. --Research Qs:(see slides) ---What are important performance metrics? ---How to measure them in a realistic scenario? ---How to make measurements reproducible? ---How can performance be predicted with models? --Testbed: 15 Servers/with 10G and 40G ports (slides): Servers exclusive to his work. SDN switch/routers; Reproducibility maintained re quality controls. --Working at the interface of software and hardware to achieve fast software packgen - has full control - written his own code and all packets through his code to maintain quality/consistency for: Fast, flexible, Timestamping, Rate control, Free and open source - code on github: https://github.com/emmericp/MoonGen ---Slides of measurements graph - see more in paper on github - but point in showing slide: interface burst size/latency/perf/optimization - CBR; CBR traffic issues. Lab vs real-world - CBR is not real world ---Architecture slide; Generating complex packets slide (v4 and v6) and packet generation specs; script or using their CLI slide ---How are others using MoonGen? Slide on 5 use-cases ---Looking for users to continue testing Q&A: --Q/Bogdanovich: Packgen an issue/thank you --Q/Chair: Would you come to one of our Hackathons to look at testing on the fly? A/Yes - London --Q/Al Morton: Comparisons between packetgenerators and sensitivity - seen this in other testing. What would u say to a spec that calibrators the generators (notes that this might be valuable)? A/interesting idea and points to stats re Rate Control Comparison and MoonGen Rate Control (and Q re how to do this…) ---Speaker - need to learn from range of work and CBR streams not realistic. Need specs in benchmarking and look at real streams of traffic… 2nd ANRP Speaker Roland Van Rijswijk (Univ of Twente and Surfnet) ECC + DNSSEC: The Performance Impact of Elliptic Curve Crypto on DNSSEC Validation -June Thesis defense (clapping) (SLIDES) --Packet frag when deploying DNSSEC. And 10% of resolvers have trouble with same. --DNSSEC has been used for DDOS --Issues related to response size (earlier paper looked at RSA and default algorithm --Can ECC be used instead: ---ECC smaller keys and signatures. Why not change? ---RFC 6605 (Standardized elliptical curve digital signature) - ECDSA slower than RSA with result that possibly doing this and switching to ECC could push problems to the edge of Net --Paper Goal - If you switch to ECC - How does this impact validating DNS resolvers? ---predict the number of signature validations - based on the number of outgoing queries ---lack of DNSSEC deploy - not every response contains the same number of sigs ---Possible not all signatures need to be validated ---Were not measuring the number of queries from ciients as this will vary strongly between resolvers --Measurement setup (slides contain detail) ---traffic to production DNS resolvers - to instrumented DNS resolver ---Paper also looks at ethics ---Plotted factors (slide) - observed behaviour ---Resolver model (slide/paper) validated according to 4 criteria; measured at diff times over five months and compared the model parameters. Used traffic from 4 sources to look at a range of traffic and look at worst-case estimations ---Benchmarked 5 implementations on modern CPU ---Benchmarking results: Order of magnitude slower - slower than quoted in RFC 6605 ---Key Benchmarks - why chosen - variety of factors (slide) ---Estimating future performance in switching over from RSA to ECC/using +/-150 validations per second ---If all deployed DNSSEC using ECC - what does it do to resolver ---Results: Ample room for growth in DNSSEC deployment and outgoing query load (see chart) ---Results Using BIND: BIND validates 2.4x (varying theories re why) - ECDSA P-256 Clarification (because it is not explicitly included in the slides): BIND validates approximately 2.4-2.5x the number of signatures that Unbound does. Possible explanation is validation of signatures in auth/additional section, but needs deeper investigation to verify. ---Additional Benchmarks - looking at other architectures ARM and MIPS CPUs - Perf is low, but sufficient for home scenarios ---Student ran test (kudos for ethics check pre-running): n=1 home router experiment, 10 concurrent users, slower in this environment ---End with some insight into adoption: until 2015 virtually no adoption of ECDSA signing schemes standardized in RFC 6605; Late 2015 - CloudFlare first DNS operator to adopt ECDSA; in .com .net and .org - majority still use RSA SHA1 (not considered secure); CloudFlare announces “universal DNSSEC”; more operators using ECDSA second algorithms used after SHA; .nl and .se examples; Alexa top 1M Clarification: RSASHA1 is secure in principle, because it is hard to exploit the fact that SHA1 has hash collisions in the DNSSEC scenario. This would require control over the signing key; if an adversary gains control over this signing key, you can generally assume you have bigger problems. Nevertheless, in many scenarios it is wise to choose SHA256 as hash algorithms, hence the remark. Slides have been amended accordingly. --ECC sufficiently performant for widespread adoption in DNSSEC (thank you to students working with him) Q&A: Q/- more a comment: BGPSEC High perf (their company) - look at paper re same presented NANOG 69 in Feb 2017. Has measurement details in paper that could be useful. Q/Wes - thank you/good measurement work. 2 things: providing guidance to signers, but the resolvers issues. If there is DNSSEC use uptake, imagine a case where there could be a prob. It would be interested to look at DNSSEC adoption and CPU increase in speed - with an early warning system. A/some discussion in paper re this. Assumes people have CPUs to handle. Ran some other validation tests. Can kill BIND, but suggest ways to solve. Q/Analysis of the no of sigs validated unbound and BIND. Can you say something about ideal - build an ideal resolver - what are the number of signatures I need to validate? A/Platonic resolver - interesting given factors between BIND and unbound. PhD working on resolver issues and likely can be tested. Optimal resolver Q’s. Q/Willem Toorop, NL Labs - important to find right measurement metrics, but some factors that may be unexposed (one single factor) have you looked into the Gallimaufry factor. A/Looked at it. Factor/Queries leading to ECC validation. See slide re expected/unexpected factors. IMPORTANT NOTE FROM ALLISON: I think most of the audience noticed that the Gallimaufry factor was a spoof. I had challenged Willem (with whom I work on an open source project) to use the word “gallimaufry” (because it is so unlikely) at 3 mic lines. Willem and Roland created the spoof about the Gallimaufry Factor as a surprise for me. Hence my laughter throughout. I hope it was fun for others :-) Q/Mat F; uptake in growth followed by flat re Adoption of ECC/why? A/One operator switched to ECDSA P256 - a omain Name Shop (Norwegian). Some adoption (hard to see on graph). Algorithms roll-over entails new steps and you must have signatures for algorithms. If steps not followed, Domain goes bogus. Company that switched algorithms did it successfully. Notes that past roll-overs have had hitches. Swedish registry one to watch on future uptake as will be conducting measurements when they do. Chair - Anyone else with Questions of a general nature? --No questions Chair: Present certificates - will be done after meeting ends along with photos. Time given back to folks. See you in London! Close at 11.32