Skip to main content

Minutes IETF118: irtfopen
minutes-118-irtfopen-04

Meeting Minutes IRTF Open Meeting (irtfopen) RAG
Date and time 2023-11-09 16:00
Title Minutes IETF118: irtfopen
State Active
Other versions markdown
Last updated 2023-12-01

minutes-118-irtfopen-04

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.