# IRTF Open Meeting Thursday, 9 November 2023, at 17:00-18:30 Central European Time Room: Congress Hall 1 Chair: Colin Perkins Minutes: Colin Perkins Recording: [YouTube](https://www.youtube.com/watch?v=kIAlMPW7_CM) ## Introduction and Status Update Speaker: Colin Perkins, IRTF Chair [Slides](https://datatracker.ietf.org/meeting/118/materials/slides-118-irtfopen-agenda-and-status-report-01) Colin Perkins introduced the meeting. He welcomed Reese Enghardt and Vidhi Goel who join Simone Ferlin as ICCRG co-chairs. He also noted that the IRTF is in the process of developing a [code of conduct](https://datatracker.ietf.org/doc/draft-perkins-irtf-code-of-conduct/) and solicited feedback on this from the group. Nominations for the Applied Networking Research Prize 2024 are open until 19 November 2023. ## SCALE: Automatically Finding RFC Compliance Bugs in DNS Name Servers Speaker: Siva Kakarla [Paper](https://www.usenix.org/conference/nsdi22/presentation/kakarla) [Slides](https://www.irtf.org/anrp/IETF118-ANRP-Kakarla.pdf) Discussion: * Wes Hardaker: Thank you! It's clear the test cases map to the model, so coverage is good. Do you have confidence that your model covers everything it needs to cover? You didn't describe how the model was built from the RFCs in that much detail. * Siva: The model was derived manually from the RFCs, in 2020. It's a hard labour. We went through the RFCs, built a mathematical model, and used the model for the test generation process. * Jim Reid: This is great work; it's good to see a more systematic way of doing DNS testing. You found a lot of bugs in DNS software, but are they implementation bugs rather than something that's faulty within the RFCs? * Siva: The model is derives test cases from the RFCs, but when you run the implementations, some respond in a different way compared to the others; it's an RFC compliance bug. * Jim Reid: The DNS RFCs are somewhat vague, and it's difficult to use them to some formal methods for testing. This has been a problem in many previous cases. What problems have you had trying to develop the models, particularly from the historical DNS RFCs? * Siva: One way we tried to mitigate these issues was using differential testing. Especially if you think of glue records, there's no right answer on when glue records should be returned or not, so we were not sure how to model. We modelled in one way, generated test cases, and compared responses across all the implementations. If the majority respond in one way, they assume this is the correct interpretation. ## Design and Evaluation of IPFS: A Storage Layer for the Decentralized Web Speaker: Dennis Trautwein [Paper](http://www.eecs.qmul.ac.uk/~tysong/files/IPFS22.pdf) [Slides](https://www.irtf.org/anrp/IETF118-ANRP-Trautwein.pdf) Discussion: * John Levine: Thank you, this is interesting. Was wondering if you were able to characterise where is the data actually stored? * Dennis: This particular study didn't consider this, but there other work that studied this and is linked from the talk (https://dl.acm.org/doi/10.1145/3618257.3624797). * Colin Perkins: This is a content addressable system; does that have any implications for privacy and being able to trace who's looking at what content? * Dennis: There are big implications. When a request is sent to the immediate neighbours in the network it gives away information about the interests. There are efforts underway to address this using double hashing and other techniques to obfuscate requests; work in progress. * Georgia Osborn: This is a peer to peer system, so the content is delivered through multiple peers. Does that mean that as the content is distributed, all peers are responsible for that content. If it is illegal content, does that mean everyone is then responsible for that illegal content? * Dennis: The illegal content will stay on the hosting machine. Other nodes participating in the DHT will host provider records that point to the content. No-one else hosts the content. * Ayoub Messous: How to explain performance gain? The increases are surprising. * Dennis: The slides showed that the provider record is stored with a single peer, but in reality it's stored with 20 peers to combat peer churn. Two years ago the fraction of unreachable peers was high, giving poor performance. Now it's significantly lower; this improves performance because there are few timeouts. * Ayoub Messous: What is the performance impact of peer location? Do they have to be geographically close to get good performance. * Dennis: No, the results relate to closeness in key space not peer location. * Jean Francois Querault: There are many different implementations listed, including Filecoin which is block chain based. What's the difference in behaviour between the different implementations? * Dennis: The definition of IPFS is very broad and comprises both CIDs and the DHT behaviour. Some of the implementations just implement a subset. Many of the web 3 implementation use just CIDs. ## Network Measurement Methods for Locating and Examining Censorship Devices Speaker: Ramakrishnan Sundara Raman [Paper](https://ramakrishnansr.com/assets/censorship_devices.pdf) [Slides](https://www.irtf.org/anrp/IETF118-ANRP-Raman.pdf) Discussion: * Mallory Knodel: Thanks - really interesting talk. Some of the mechanisms used are similar to those used by censorship circumvention tools to figure out how to get around the block; they might be able to leverage the same mechanisms. Would like to think about how the work done can make the circumvention piece easier. * Ram: Absolutely; there's definitely value for the circumvention community. * Olivier Hureau: The slides showed only IPv4 addresses, did you try IPv6? * Ram: This study was only IPv4, but it's an easy extension to the tool. However, some of the data used came from platforms, such as Censored Planet, that only have IPv4 data available. Expect the results will generalise to IPv6 if data was available. * Christopher Patton: This is great work. If you could change anything in IETF, in TLS or HTTP or other things relevant to censorship, what would you tell those people to do? * Ram: That's a good question. Most realistic thing is to encourage more transparency. There's a lot of opaqueness of what's happening, both from the people deploying censorship tools and from the people that build such tools. Things like error messages that give reasons for blocking, who is performing the blocking, open source block list, etc., would help detect unwanted blocking. * Michael B.: Is there any reason why these devices should be able to hide what's being blocked? * Ram: These devices classify sites into categories and provide the ability to block by category. Part of the danger comes from over-broad application of categories. ## Wrap-up Colin Perkins thanked the speakers and reminded the group that nominations for ANRP 2024 are currently open.