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

Introduction and Status Update

Speaker: Colin Perkins, IRTF Chair

Slides

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

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
Slides

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
Slides

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.