IRTF Open Meeting @ IETF 106 ============================ Monday, 18 November 2019, at 15:50-17:50 Room: Padang Chair: Colin Perkins Notes: Mat Ford Materials: https://datatracker.ietf.org/meeting/106/session/irtfopen Video: https://www.youtube.com/watch?v=dxFw_MmR-uc # Introduction and Status Update Colin Perkins introduced the meeting. The Applied Networking Research Workshop (ANRW) 2020 will take place co-located with IETF 108 in Madrid, Spain, in July 2019. Mirja Kühlewind and Roland van Rijswijk-Deij will be the TPC chairs. The paper submission deadline will be in April 2020, and more information is available at https://irtf.org/anrw/2020/ Nominations for the Applied Networking Research Prize (ANRP) 2020 will close on 24 November. # Off-path TCP exploit: how wireless routers can jeopardize your secrets The ANRP winner for IETF 106 is Weiteng Chen (UC Riverside) who presented his paper on "Off-path TCP exploit: how wireless routers can jeopardize your secrets" from the USENIX Security Symposium, 2018. Daniel Kahn Gilmor: Great work. A good reminder that timing side channels can be stepping stones to bigger problems. Curious about proposed mitigations - have you had a chance to test any of these in the same environment that you tested the exploit itself. Especially the TCP-layer mitigation - did you test a modified kernel to see whether it would effect the results that you got? Weiteng Chen (WC): If you look at Linux kernel source code it does implement some mechanism for rate-limiting responses for incoming packets but only for packets that have no payload so it is trivial to bypass the check you just need to add a 1-byte payload to the packet and then there is no rate-limiting. Why Linux kernel is implemented in this way? There are many discrepancies between different OS implementations compared to the standard. Allison Mankin (AM): Like this - like the questions you asked about why TCP is the way it is, would be good to discuss these questions in the TCP working group and also the mitigations you talked about. And check on whether some new transport protocols are doing better. On slide 35, what does average time cost mean? WC: We launch the attack 10 times and then we calculate average time for all 10 attacks. AM: I wondered if connections are typically short is it much harder to make this attack? WC: These two connections are created by the JavaScript so we can send arbitrary numbers of requests to the server - connection will be kept alive for a long time AM: Attacker can keep connection open for a long time? WC: Yes. Colin Perkins: Is this specific to WiFi - are other wireless networks subject to similar issues? WC: This is a fundamental design choice of wireless protocols. There is nothing wrong with half-duplex. We discussed this issue with IEEE 802 working group - they do acknowledge the vulnerability CP: Do you know if other wireless protocols have similar behaviour? WC: No. Chris Seal: Presumably the same attack would apply to any system where the last link is half-duplex even if it's not WiFi? WC: yes, conceptually Christian Huitema: Have you considered mitigation such as using randomised delays in routers? WC: Yes, that's a typical mitigation but you need to consider implication because delay can slow down whole network which is a separate problem. I'm not sure how it can be implemented with minimal cost. # Research Group Update: COIN Marie-Jose Montpetit presented a brief status update on the Computation in the Network Proposed Research Group. This group has just completed its first year of operation, and is doing some interesting work to understand models for in-network computation. # Relation between IRTF and IETF Melinda Shore led a discussion about the relationship between the IRTF and the IETF, and on the different goals and ways of working in the two organisations. She noted that there has been some blurring of the lines between IRTF and IETF due to the way RGs are run, with some research groups getting closer to IETF processes. Some groups focus on internet drafts rather than papers, on consensus based decision making. Is this good? The IRTF should be about ideas and enlightenment, rather than specifications and engineering. Melinda Shore (MS) - seeing lots of overlap between IETF way of working and IRTF RG ways of working. That's OK but we need to be careful to preserve the IRTF opportunities to use documents that aren't internet-drafts, meet in other venues, support a diversity of opinions rather than seeking consensus and so on. Dirk Kutscher: I agree. We have to be careful not to get to ossified in the model of doing research in the IRTF. Of course it's nice to move some work to the IETF occasionally, on the other hand there is also valuable output if we are able to invalidate assumptions in relation to the Internet and move on. CP: Agree we don't have to produce things that can go further - we can explore something and say, yes that's done. Brian Trammell: Looking at list of research groups and almost all meeting. Scopes of research groups have some overlap. All considering what's next for the Internet from different perspectives. That would not work at all in the IETF. Idea of the IRTF as a sort of lab for the IETF is a good one - success isn't necessarily transitioning work to IETF. Let's keep throwing things at the wall and see what sticks model works pretty well. Need to continue pushing back on anti-pattern of RG is a consolation prize for a failed BoF. Laurent Ciavaglia: This is an important question to discuss. We can consider a stage where there is a research question or topic and where it could be addressed. Maybe IETF or IRTF have ways of addressing problems. If we think other organisations (ITU, ETSI, etc.) could help then we should consider that. Transitioning between IRTF and other SDOs / stakeholders also possible. CP: Lots of research groups have historically had close links to academic conferences in their area. QIRG and NMRG are examples. Stephen Farrell: Lots of good things about IRTF being close to IETF. Less good aspect of proximity - RG chairs find it hard to deal with a lack of consensus. RG don't need to seek rough consensus. Seems that there is a tendency for RGs to seek consensus like an IETF WG but that's not necessary - could publish something with disclaimer. CP: Agree - you don't need RG consensus to publish an RFC. You need an interesting document. Publishing interesting work regardless of consensus is fine. Equally RGs are not evaluated based on the number of RFCs they produce. Jana Iyengar: Seconding what Stephen Farrell said. It's valuable for IRTF research groups to recognise that processes of IETF WGs might be convenient because they are familiar, but they are not necessary. Certainly not required. As chair of ICCRG I've been trying to figure out what it means to publish documents in ICCRG - concluded that it doesn't really matter. Publish when it seems useful. Publish interesting documents. Not always one right answer. Useful for IRTF to be associated with IETF - it gives relevance and a space where we can understand practical problems, but also useful for IRTF to be independent of the IETF - doesn't need to be driven by problems coming out of IETF or feed outputs into the IETF. IRTF provides a distinct venue where we are able to bring people from academia, industry, standards - want to foster this cross-cutting community so that when we have problems in the IETF that needs this community we have it on hand. Melinda Shore: There does seem to be demand for engineering outside of narrowly-scoped IETF WGs. Broader discussions tend to get pushed to IRTF but they are not really in IRTF purview to deal with that - but we might want to discuss this with IETF. CP: An important point - IETF WG are very narrowly scoped, IRTF RGs are very blue sky - Agree there's a gap between IETF WG and IRTF RG scopes. Dean Bogdanovich: Agree. NMRG and NETMOD/NETCONF are example. Challenging some of the thinking in the architecture and getting new thoughts from IRTF would be useful. CP: I suspect the scheduling could be made to work if people want to have joint sessions to have these discussions. Eve Schooler: Like this discussion. In some ways discussion around relationship with the IETF is around what's our metric for success in the IRTF. Predominant one is informing IETF. But there are others. Some relationships spawning now, e.g., T2TRG have to do with relationships with broader community and other SDOs. Collectively as a research community in IETF can we catalogue and share some of those metrics and objectives. CP: Yes, that's certainly true. An RG is not necessarily expected to produce something useful for IETF. It's there to explore the problem space and produce some new knowledge. Another effort could be spun up in IETF based on that but it's not a necessary thing for success. Producing a bunch of papers and a bunch PhDs is a fine outcome. As an RG, don't feel you have to follow the IETF process don't feel you have to have consensus. It's certainly not inconvenient to meet at IETF meetings, but meet in other places, run workshops, conferences. Do whatever helps advance your research. Allison will remember reliable multicast group meeting on the beach in Cannes next to the SIGCOMM conference. Tim Wattenberg: That also promotes the IETF in those other places. We talked a lot about how the IRTF can contribute to IETF but also the other way around this is an opportunity to get new people interested in what we're doing in the IETF as well. CP: It's a way fostering discussion between the industrial side and the academic side. # Moving work between IRTF and IETF -- Aaron Falk and Laurent Ciavaglia Aaron Falk presented some thoughts on moving work between IRTF and IETF, building from a discussion with Laurent Ciavaglia. The slides suggested some examples of IRTF-IETF collaboration that have worked will, that were less successful, and where the outcome was uncertain. Alison Mankin: Can you define 'uncertain' on your slide? AF: This characterisation is 'it's not obviously a good example or a bad example of IETF/IRTF collaboration' - uncertain as to whether it's a good example or an anti-pattern. AM: I'd add end-to-end was a task force and a peer of the IETF so a different animal indeed. It incubated our entire Internet media protocols, diffserv, ECN, so what kind of thing could be like that in future I'm not sure, maybe nothing, but it was very high impact on the IETF but different from the RGs we have now. Stu Card: Agree with characterisation of HIP burst of promising activity and then long periods of silence. Rumours of HIPs death have been exaggerated - not a poster child for transition - may have transitioned early before there was a strong application pull for the technology. BoF tomorrow morning is an example of application pull for which HIP may be a perfect fit. AF: HIP in our time! Very exciting. Christian Huitema: There have been closed membership and open research groups historically. Any relationship between that and success? AF: The only two closed groups I know of are on this list (NSRG and End-to-End). Have a positive and a negative example. I don't think there have been any closed RGs in recent memory. The IETF has a very constrained process because we want to be an open transparent standards organisation - the IRTF has none of that. Making a group closed is one aspect of the freedom that the RG chair has to organise their group. David Black: End2End was closed in that membership and participation was by invitation only but chairs invited everyone they could that seemed clueful. Different forms of transfer is really insightful identified on your slide are spot on. 'Transfer' RGs need the courage to close down when transfer is done. Area of overlapping expertise for both ICCRG and CFRG - you can identify a community of expertise strongly grounded in research that is complimentary to the standards work. AF: Laurent should get credit for this slide. Wes Hardaker: NMRG was also root for netconf and YANG. A short-term model that has heavily impacted IETF today. Started as a fairly short project but still too long to do in the IETF. It's a great tech transition story. Dave Oran: You focussed on a bunch of things in the IRTF that have had interesting characteristics in their interactions with the IETF. We should look at failure models too. Some RGs wound up getting chartered and then we discovered that there actually weren't any interesting research problems. Couldn't produce a standard as not in IETF, but what was happening in those RGs wasn't research. Need to guard against allowing groups to go on and on without doing useful research work. There have to be interesting research problems independent of the question of whether the output is of interest to the IETF. CP: This is difference between research and development. AF: I think there's room in the IRTF for both if there's an energised community that wants to work on it. IETF proceeds on things that are pretty well-defined. There are a lot of different kinds of things that can grow in the IRTF. I don't see a benefit to creating another organisation to hold those things. It's that research and implementation collaboration joint expertise that it takes to get them over the line. They don't always succeed. CP: We need to be clear that we believe there are research issues before we charter a group. If it's long-term engineering it should be in the IETF. AF: Hard to draw a clear line between research and engineering in some cases. CP: There's a grey area. AF: Judgement is yours. Spencer Dawkins: Thanks to Colin for bringing this topic forward and Aaron for giving this presentation. Seems like when we succeed in research groups we do that by involving a lot of people that don't understand the IETF very well. That makes transition hard if they don't know what's been tried before and worked out badly. RFC7418 - IRTF primer for IETF participants - addressed to people from IETF. That was the problem the IRTF chair was dealing with then. We don't have same RGs, IETF or chair now. Seems like problems IRTF chair is facing now is more getting things well organised on first outing so that we don't have failures. Documenting what models are. I would caution against trying to make this very precise as RGs have large scopes and are very diverse. Do for IRTF / IETF interaction what PANRG draft on what not to do does. Wes Hardaker: There's a width issue - IRTF groups need to span from far distant research to stuff that is ready to transition to engineering. There are different models of success. Success possibilities are so wide it might be easier to describe what we don't want. Failure to find an audience, failure to produce documents, discovery of deficiencies failed to transition to fixes. AF: Most insidious example of something that doesn't belong in the IRTF is a company proposal that is trying to create something that looks like an open forum but doesn't have a constituency. I saw several examples of that when I was IRTF chair - could be interesting work, but it's your narrow thing so not going to create a group. Erik Nordmark: Interesting debate about boundary between research and advanced development. I think there is question of IETF/IRTF relationship when new work arrives and proponents don't seem to be able to describe the problem very well. Those things tend to get tossed around. IAB might get involved, but that's a challenging space where we believe we want to be open and invite new work but it's not always well formed. We should collectively find a way of handling that. AF: Excellent point, do you have a proposal? EN: No! Rich Salz: It's always good to write things down. Need to be careful that it doesn't become a requirement that research must successfully transfer. Learnings drawn from research side vs. IETF side may be very different. AF: Should have included a column for 'nothing transitioned but it was still a great thing'. CP: Thanks Aaron. There is no requirement for work to transition from RG to WG in order to call RG a success. As an RG the idea is to develop some ideas. A group of people may look at the output and identify it as appropriate for standardisation, or they may not. It's a success either way. # How can the IRTF help academia (and vice versa)? Marie-Jose Montpetit led a discussion of how the IRTF and academia can work better together. AF: One idea not on your slide implemented by NMRG is they did pre-publication reviews of papers (needed some confidentiality to be able to do that). Folks perceived that as a real benefit. MJM: Good idea. Wes Hardaker: Told recently that I had 0 academic papers and a couple of RFCs that wasn't good enough. This year I have a couple of academic papers and 0 RFCs because RFCs are taking longer to get through the system. IETF/IRTF not listed on academic rating scale of conferences. MJM: It's uneven. Our goal is to bridge the gap where it exists. WH: My supervisors absolutely know what IETF is, but it's still a problem of academic grading. CP: It's interesting the way different countries evaluate the research. In some places research impact is considered important, other focus just on research papers. Allison Mankin: I'm inspired by your bullet about vision or blue sky papers. From my time at NSF fields have 10 year horizon planning somewhat formally, is very valuable for those fields in terms of getting funding. Could do that here too. MJM: Thank you. Dean Bogdanovich: My participation in RGs and reading academics, how I can I know who are the leading participants? MJM: I think I'll sound like a social media guru here, but we are all at the centre of a large number of connections and we can reach out to leaders. If they cannot come they'll suggest somebody else. We *are* connected. If we invite people we'll get people. Eve Schooler: I keep seeing conferences including invited blue sky papers. How do we get academic community to change their perception that RFCs aren't as important as academic papers. I wonder if we can reach out to some of the communities like NSF or DARPA that are looking at the challenges and have a seat at the table. MJM: I think there is an example of how this works - IETF used to be only US people, also a reviewer on European research projects - at one point somebody put in outcomes for dissemination was participation in IETF and European participation shot up. Maybe there's a similar thing we can do. Christian Huitema: RFC now have OID reference on every RFC precisely to facilitate citation of RFCs in journals. One can easily count the citations of an RFC on various libraries as a way to give weight to publications. MJM: Yes, thank you. Markku Kojo: There's a very good paper published in ACM CCR by Brian Carpenter and Craig Partridge that discusses the role of the RFCs and how to cite them (DOI: 10.1145/1672308.1672315) Dirk Kutscher: This presentation and discussion is suffering a little bit from projecting known methods of working from the IETF to IRTF research and then wondering why this doesn't work for academics. Standards track RFCs take time but that's not what we are doing in the IRTF. Two key criteria - useful output for IRTF in some way, and doing useful relevant high quality research. So could be interesting to discuss indicators or models that seem to work well and ask the question what's the point of writing a draft or an RFC - a means to enable experimentation - to be a able to take academic research, keep people honest and gain some insights from that. I would kind of turn this around and ask what are good indicators and good models that work well. MJM: Thank you Jana Iyengar: Drafts have a use, but perception in academic perception is uneven at best, but that's true for all drafts in all worlds. As an academic who's gotten tenure based on publications I couldn't rely on RFCs. We can't change perception, it's a real issue in the sense that goals of what we do and what academic publications do are different. MJM: Why is that the case? We want to foster good research. Papers presented out of ANRP are always top-notch. We're not doing second-rate stuff, and I think that's part of the perception. JI: I want to disagree with the idea that we do research in RGs, we foster research. There are groups that go off, do research, publish, come back and report what they have done. They'll keep coming back, they don't use us a publication venue, as an RG we don't publish but we are engaging with these groups and creating a forum for that to happen. We foster research - we allow and encourage research to happen. Metrics should not be publications. Dave Oran: I do research, I run an RG, I participate in RGs. If I have a great idea I'm not going to submit it to an RG, I'm going to write a paper and submit it to a double-blind reviewed publication venue. What RGs are most successful doing is this collaboration function. Academics don't collaborate very well - forced to by their funding agencies. We have a good joint NSF and Intel wireless edge computing and ICN - we have a zero record of anyone working on that coming to present to RG - it's extra work for no particular benefit in those contexts. So we have to push this collaboration and community aspect and make our case based on that vs. the idea that we're doing great research in the IRTF. MJM: Want to create an agora. CPL: Thank you. Thanks again to Weiteng for ANRP presentation and thanks to everyone who contributed to this interesting discussion. Hopefully it can continue throughout the rest of the week. 17:50 Close