[irtf-discuss] Draft Minutes of the IRTFOPEN meeting

[Allison Mankin <[e-mail]>]

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 [e-mail]

-{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