[irtf-discuss] Draft Minutes of the IRTFOPEN meeting
Allison Mankin <allison.mankin@gmail.com> Fri, 17 November 2017 20:50 UTC
Return-Path: <allison.mankin@gmail.com>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6312751F; Fri, 17 Nov 2017 12:50:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqJNzTUlP53b; Fri, 17 Nov 2017 12:50:43 -0800 (PST)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33E81200B9; Fri, 17 Nov 2017 12:50:42 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id p9so2770656pgc.8; Fri, 17 Nov 2017 12:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=CE6+U0YdsNvb2HbyblzG1kD8QEeOKXYs6zGDIInxk00=; b=NP0RRs0Dp6HeW2NmU7sW8I8R7Pf3Ezf2hSzrrzCGPM4ZkmnSzN8/D8W5pwUUiQeIk9 9hMv6LhAgoHZM9CuSh1AvyZIC0iRYobajFgaOO3CcCqljq5RBfS1xHFqGtvp80ziToa8 Sg0RLGMHTZxvRrsw2wjm7rKhxYRmTGepzZXTcQwEr/Jw2NnXLcsumLPyFy6ni3lxmUk+ HRhVllVAy5bNR5+AXY0YzlxGVj27F7+fOVBptZqdSjszD/LiBd2lwGT6A+sveWX/mDov p9QbMOo6FXZa5x/BTDod3Bwba3LRwKEhrTGSxErt1l4ewCRHWtZYfopPwCPGjpjKt5BT NvDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CE6+U0YdsNvb2HbyblzG1kD8QEeOKXYs6zGDIInxk00=; b=EMUJ5r8P29408PLKS8sJtR4hnQQ2bRy2jHLcMq7LIgvdHdgkwtsfYLBuYczY7xVl1M FLGjAdq8ic3/wPl5K8QQ267FtBfPVfLDZfqV/9IsMZU6O8RRdOwvl4xRLhT49NrpM3V1 5i8Wt08fevwNlBGUyfZoJgAY60DSUmr+WTuQ3HnKOJA+WvJZsXZBnmqLz3tcumJLBgcY s2LpVcDV8rKCrfdriEN2IKa1Qm4SvDT88DPYK+0JegVfIjajUAURP1tyZuykdjwvJ7/E WCee0+XBvi2VPAQeWN0UfDxVy8aFdsFAzZC952aDMNoXlLQwYToxlb9nnRGGcQ673kCr BxVg==
X-Gm-Message-State: AJaThX7RXpw57Asri0OJShI5N+kxIGgeBV6KxAuxNyL8ocNUPd47oKR7 zroP+/+pbFuYWYq/w1isMN/xeWJdrdzZHXb+C2N3uA==
X-Google-Smtp-Source: AGs4zMZleajmRTsWytMm3wlKVNcff2g4dgjhdllnyTYBqEeTWo3CF5PB3U9rbHs0NIrMGmByWwsVq2+3keImA56oXAA=
X-Received: by 10.99.64.5 with SMTP id n5mr6176566pga.244.1510951841953; Fri, 17 Nov 2017 12:50:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.180.132 with HTTP; Fri, 17 Nov 2017 12:50:41 -0800 (PST)
From: Allison Mankin <allison.mankin@gmail.com>
Date: Sat, 18 Nov 2017 04:50:41 +0800
Message-ID: <CAP8yD=sbDMRJCPJ8pAW7LH3u-U4mFmzoHmB6qHNGVo7rG57fDw@mail.gmail.com>
To: irtf-discuss@irtf.org
Cc: "Internet Research Steering Group (irsg@irtf.org)" <irsg@irtf.org>, Roland van Rijswijk-Deij <r.m.vanrijswijk@utwente.nl>, Paul Emmerich <emmericp@net.in.tum.de>, Jane Coffin <coffin@isoc.org>
Content-Type: multipart/alternative; boundary="94eb2c076d2acffe81055e33e3c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/jjhIk18t_p2TzR7w3g931jgSm0g>
X-Mailman-Approved-At: Fri, 17 Nov 2017 13:32:06 -0800
Subject: [irtf-discuss] Draft Minutes of the IRTFOPEN meeting
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2017 20:50:47 -0000
Thanks very much to Jane Coffin (GAIA co-chair) for taking notes during the IRTFOPEN meeting and thanks to the ANRP awardees for a great session. All the slides are in the Meeting Materials. I edited Jane's notes a little and here are our draft minutes. Please send any corrections/additions soon. 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 ---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 --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
- [irtf-discuss] Draft Minutes of the IRTFOPEN meet… Allison Mankin