Opening Plenary, Monday, 22 Nov, 10:30

Chaired By: Mirjam Khüne and Niall O’Reilly
Scribe: Antony Gollan
Status: Draft

A. Welcome to RIPE 83!

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/23-RIPE-83-Opening-Plenary.pdf

Mirjam Kühne, RIPE Chair, welcomed attendees. She noted that they had a new Code of Conduct in place for this meeting. While they didn’t have a Code of Conduct Team in place, the existing trusted contacts had volunteered to stay on for the duration of the meeting. Mirjam said she was happy they were having another Rob Blokzijl award opening on Wednesday. They had a revised version of their Policy Development Process (PDP) document that was announced via the ripe list. The RIPE DB Requirements Task Force had published its updated report. They had an NRO NC Election at this meeting and videos had been shared in the Address Policy Working Group from the candidates. Mirjam thanked Nurani Nimpuno for her work on the NC. Mirjam said she’d hold the questions till after Hisham ran through some of the housekeeping from the RIPE NCC’s sides.

B. Meeting Logistics

Hisham Ibrahim

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/17-Meeting-Logistics-.pdfHisham ran through some of the logistics around using Meetecho (the meeting platform they had used for the past three RIPE Meetings).

Eric Bais, Address Policy WG Chair, asked Mirjam to remind the audience to watch the pre-recordings for the AP-WG session tomorrow morning. so that we can have most of the time for discussions.

Mirjam reminded people to check the agendas of WGs before the sessions, as there were pre-recorded videos for some WGs.

Franziska welcomed people on behalf of the Programme Committee.

Plenary, Monday, 22 Nov, 11:00-12:00

Chaired By: Franziska Lichtblau, Jan Žorž
Scribe: Antony Gollan
Status: Draft

A. Responsible DisclosureGiovane Moura, SIDN Labs

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/19-presentation.pdf

Giovane talked about the different approaches that people could take for responsible disclosure, using TsuNAME (a DNS vulnerability) as an example. He said that researchers had an obligation to responsibly disclose vulnerabilities when they encountered them. He said it took time, energy and patience to do disclosure, as they needed to do this with multiple venues (and languages). He said trust was essential – they had used PGP and they were very transparent. He also said they should check with their legal teams to make sure they’re covered. He noted you couldn’t keep everybody happy – in their case some people had been positive and appreciated this, while others were negative and accused them of creating fear. The goal wasn’t to make everybody happy – it was to enable people to fix their software and mitigate the vulnerability. He noted that feedback from Randy Bush had motivated them to write an IETF draft that was under review. He noted that Google had awarded them a bug bounty, but IRS requirements meant they’d have to complete a detailed 8-page form.  All in all, he thought they’d had a positive outcome from all of this.

Brett Carr, Nominet, commented that they were interested in ensuring that vendors also do responsible disclosure to customers of fixes in a staged manner so that operators of critical internet services get to know in advance of the public exposure. This allowed critical operators to patch their systems before a critical vuln is well known. Some vendors do this already but many do not.

Erik Bais, A2B Internet, shared that on the tax issue, most software companies have local offices (e.g. Dutch Google). That might fix the US tax issue.

Giovane said they had wanted to donate the money anyway, and that they didn’t want to fill such a long form.

Peter Hessler, OpenBSD project, said he would like to make some clarifications about OpenBSD's stance on disclosure. First, for security issues that we ourselves discover in OpenBSD: we develop the fix, prepare the patches, and only then do weannounce the fixes to the public. When outside groups contact OpenBSD developers about a security issue, normally our developers will agree to reasonable conditions so we can fix our own software and assist others to fix their software. OpenBSD is not a legal entity, and cannot sign any NDAs or contracts; only individual developers can.

Giovane said in their case, they hadn’t applied a legal NDA and had just trusted them. He thought this made things much easier, especially as he knew personally in these companies. In the DNS-OARC the group already had a duty to confidentiality that made disclosure easier there. In other venues that had simply trusted – perhaps this was a naive choice – but this is what they had done.

Daniel Karrenberg, RIPE NCC, asked the audience if there was a mechanism to reach all operators of critical infrastructure worldwide and who determines who is such an operator.

Franziska mentioned that this could be a discussion that could be followed in SpatialChat.

Giovane asked if someone had previous experience with private/responsible disclosure. He mentioned that a big downside of this is that responsible disclosure generates a lot of work for vendors.

Michael Richardson, Sandelman Software Works, said they got dozens of fly-by reports and said people wanted their CVE number as soon as possible so they could get a bug bounty. They rarely followed-up with more details. Usually, they don’t have test data that demonstrate the bug. It would take them between 2 and 20 hours to validate each report on an open-source project – so he couldn’t imagine what it was like for other vendors. So if he wasn’t getting a good response from other vendors, this was the cause. They now had a significant ecosystem of people running fuzzers who were depending on bug bounties to pay for their electricity. As an OpenSource project they also had to maintain an alternative fork to maintain privacy while they worked on it. The funniest part was they disclosed to Apple and they said 6-10 months to do this – were they supposed to wait for an acknowledgement before they disclosed this. In other cases, people asked them to agree to a 90-day period, but they declined and said people should just disclose, given the number of items in their queue. He said it would be nice if they could setup a ring to track people who were clueful and not-clueful. There was too much work and they literally needed secretaries to sort this out. If operators didn’t have resources, projects like his did.

 Giovane said he had no idea that bug bounties provided such an issue.

 Michael said he would add that there was some other new entity that said they would give 20% of the bug bounty to the project. He was skeptical about this. It was a great idea – he didn’t know if 20% was the right number. If someone was to provide a patch or to reproduce the bug, perhaps. Then you went through the process of asking how to write the patch and which forks to apply it to. If it was just a report – someone might have been one of 10 people to report it.

Giovane said in their case, reproducing the bug had taken a large portion of the work. And unless people did this, that was the wrong way to go about it.

B. Troubleshooting with QUIC

Isabelle Hamchaoui and Alexandre Ferrieux, Orange

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/26-RIPE-loss-bits.pdf

Alexandre presented on QUIC which was basically advanced TCP/IP with encryption. It had grown significantly and was now about 30% of traffic on Google. It had been published as an RFC in the IETF this year (RFC9000(?)). Many troubleshooting methods used for TCP/IP were not available in QUIC. They had investigated alternatives and brought these to the IETF, but had gotten a lukewarm reaction there. He thought they had a very serious threat to the day-to-day action of debugging the network. They were concerned this could be an issue. One question might be whether packet-loss was really that critical and why they should worry about it today. BBR-QUIC and BBR-TCP/IP addressed this somewhat, but there were other cases where they needed to locate the fault. They thought that their lightweight mechanism should be pursued with other methods.

Benedikt Stockebrand, Stepladder IT Training+Consulting GmbH, asked what the reasons Facebook and Mozilla gave to oppose their idea.

Alexandre said there were two parts: privacy – where someone could use this to slightly increase linkability. The other reason, which he thought was bad faith, was that there were other fish to fry. When you were writing such an ambitious protocol ad QUIC, you had to solve other issues first – so they deprioritized this and told them to come back at v2.

Benedikt said that this was not great to hear. If you wanted to do a big project, you had to get everything right.

Brian Trammel, Google Switzerland GmbH, said that it will be interesting to look at the loss and the latency signal for further research.

Alexandre said there were some cases that were orthogonal. But those were a tiny corner case. These did not build up RTT at all.

 Brian said it would be good to see both in the same in-band signal.

Someone in the chat asked if there was a version of their proposal they could review.

Plenary, Monday, 22 Nov, 13:00-14:00

Chaired By: Dmitry Kohmanyuk, Mohamad Boroumand
Scribe: Evelien Schilder
Status: Draft

A. The Enemy is Us: On the Sharp Edges of Internet Governance Culture

Dr. Corinne Cath, Oxford Internet Institute

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/9-Cath-Corinne-RIPE-2021.pdf

Dr. Corinne Cath, Oxford Internet Institute, presented her PhD research on the IETF's culture in Internet governance. She found that the IETF’s culture plays a role in excluding important voices that have meaningful contributions to make, such as women and minorities. This does not happen by actively blocking access, but by having a culture in which direct, rough and heated interactions are normalised. She therefore stated that an open governance culture should not be mistaken for an accessible culture and proposes organisations to look inwards and acknowledge who is excluded due to these rough edges within organisational culture. 

Vesna Manojlovic, RIPE NCC, asked about Corinne’s advice on small steps that the RIPE community can take to become more welcoming and diverse. 

Corinne answered that the RIPE NCC has already been having these conversations with the community and that it is making its values explicit through a Code of Conduct. Although that is a good start, she recommended to not only think about a Code of Conduct for when something goes wrong, but to also think about what we can do to change our culture so that we never need to use it. 

Koen van Hove, University of Twente, asked what is the main thing individuals within the IETF can do to create a more accessible and welcoming environment.

Corinne answered that it is important to keep critical discussions but without making them acrimonious. She also said that technical expertise appears in diverse ways. People should not automatically assume that someone cannot be an engineer or have technical skills based on their gender or how they look.  

Giovane Moura, SIDN Labs, acknowledged that engaging in the IETF has been a scary process for him as well. He asked if there are any other communities that do similar work that are more open and that we could take as an example to learn from.

Corinne answered that her work did not necessarily go against the IETF. It just described what it looked like as an outsider and that a lot of people within the IETF are doing really hard work to make the culture changes. She does think that the Python community and RIPE are examples of communities that are making important changes. 

Jan Zorz, 6connect, stated that the message with what is wrong and what needs to be done has been sent and heard but no further action was taken so far. He asked where we would go from here.

Corinne answered that there is recognition that this is important, also due to dwindling numbers in the IETF, and that there is a drive in the IETF to make changes. The more toxic behaviors are actively addressed, if only for the interest of its own continued existence. 

Benedikt Stockebrand, Stepladder IT Training + Consulting GmbH, stated that the IETF is different from the RIPE community in the sense that the IETF is largely dominated by americans. They bring their own culture which is harder. There is also a cultural clash with the far East. The RIPE community is more homogenous. As a Working Group Chair, however, he also sometimes finds it important to tell speakers who are not from such a culture to not take a direct question as a personal attack and intervene if things get out of control. He does think that the RIPE community is a lot easier on this than the IETF.

Corinne responded that that was very clear and she appreciated that.

Niall O’reilly, RIPE Vice Chair, echoed Benedikt’s point that the Anglosaxon culture is more about confrontation and testing ideas and asked if the edges are less sharp in different cultures and countries.

Corinne said she appreciated the question and answered that she is not averse to having direct and hard conversations, but that it is important to keep it professional - to keep it about the subject and not about the speaker.

B. Janata Wifi - Affordable Internet for the Community by the Community

Sheikh MD Seum

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/15-janata-wifi-affordable-internet-for-the-community-by-the-community.pdf

Sheikh Seum, Janata Wifi, presented a solution to provide affordable Internet in Bangladesh. Mobile Internet is very expensive and as a way to mitigate this, tea stalls in Bangladesh now provide a WiFi solution directly to its users. This is both faster and cheaper compared to mobile Internet solutions.

Jan Zorz, 6connect, asked if they also offer IPv6 access or just IPv4 through CGN (Carrier Grade NAT) which is clearly causing problems.

Sheikh answered that they do not have IPv6 yet at the time in Bangladesh. It is only around 1% or less than 1%. He stated that they therefore cannot avoid the CGNAT issue at this moment.

Gordon Gidofalvy, Ting Fiber, asked if they also assist or handle setting up the fixed connection to the tea stalls as it does not seem an easy task. 

Sheikh answered that they do not handle the setting up process. They use an app which makes it easy and convenient to set up the hardware. Local ISPs help the tea stall owners to set up the process.

Dmitry Kohmanyuk, Hostmaster Ltdhe, was very impressed by the project and said that it is very expensive in the Ukraine too and suggested exporting this idea to other countries as well. 

Sheikh answered that they are trying to do that and that that is why they are sharing this with the community and they welcome anyone to contact them.

C. Help Us Build a Sustainable Digital Economy

Michael Oghia, Sustainable Digital Infrastructure Alliance (SDIA)

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/6-RIPE-83-presentation.pdf

Michael Oghia, Sustainable Digital Infrastructure Alliance (SDIA), stated that ICT sustainability covers a wide and complex range of issues and topics. The Sustainable Digital Infrastructure Alliance created a roadmap to bring all of these areas together. This is aimed towards moving sustainability forward in a way that is inclusive for the entire sector and to drive progress forward to create a sustainable digital economy. Many organisations have already joined the Alliance and they are looking for more contribution and input.

Vesna Manojlovic, RIPE NCC, asked if Michael knew how many of the RIPE NCC members are also SDIA members and if he wanted to see a show of hands.

Michael asked if anyone here is part of the SDIA (no answer) and Dmitry Kohmanyuk recommended that they could chat offline. 

Peter Hessler, Internet citizen, asked if any SDIA members are involved in bitcoin/blockchain, and how they justify their participation?

Michael answered that he is not aware that any of their members are working on Blockchain, bitcoin or other currencies. They are a member of an organisation called the crypto climate accord and stated that a lot of work needs to be done in this area, not just regarding power use but also regarding the equipment and hardware. 

Dmitry added that not all blockchains are the same and that some crypto currencies claim to do better than others. Regardless, it remains an issue. 

Jan Zorz, 6connect, asked if anyone would be interested in a sustainability best current operational practice document. Michael responded that people indicated that there is support for that and stated that if anyone had any other questions or were interested in the work, he would love for people to reach out.

Plenary, Monday, 22 Nov, 14:30 – 15:30

Chaired By: Fernando Garcia, Brian Nisbet
Scribe: Kjerstin Burdiek 
Status: Draft

A.  Sovereign Internet and the Number Resources

Alexander Isavnin, Free Moscow University

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/29-Sovereign-Internet-and-Number-Resources.pdf

Alexander Isavnin gave an update on Russian regulatory practices that are intended to ensure the nation’s Internet sovereignty. Russia began introducing these practices in 2012, and recent efforts have focused on Internet numbers specifically. The “Sovereign Internet” law in 2019 created a formal framework for these number resources and created obligations for resource holders, registries and reports. Other decrees and instructions have also been published that further regulate Internet routing. However, these regulations often come in the form of non-public documents. There is also no collaboration with the international community, and the RIPE NCC’s technical adviser was even expelled from the country, further isolating Russian Internet regulatory efforts.

Marco d'Itri, Seeweb, asked if Russian IP carriers must also export NetFlow data from the parts of their networks located in other countries. Alexander said there was no specific legislation on this, but regulators might sometimes have instructions requiring it. It would be interesting to see how international carriers followed these requirements.

Blake Willis, Zayo Europe, asked if Alexander had seen international carriers leaving the Russian market due to these requirements. Alexander replied that he had not yet because the court cases defining these were fairly recent, and they mostly concerned smaller organisations like educational institutions. International companies had not yet been affected.

Sergey Myasoedov,NetArt Group, asked whether mirroring the RIPE Database was enough for regulators. He also asked whether Alexander had any information on whether they wanted to manage IP space using their registry. Alexander said that legislation often requires registration information from resource holders, so regulators might want to use something like the Database.

Vasilis Ververis, Magma Guide, asked if VPNs that were not blocking certain resources were blocked in Russia. Alexander said that some of them were. Regulators were required to block VPN providers that did not block illegal resources in Russia. However, if the VPN provider was in the registry, it was not blocked.

Dmitry Kohmanyuk, Hostmaster Ltd., asked if there were any penalties for non-compliance, such as fines or jail time. Alexander said that there was no jail time, but there were fines. These ranged from €500 to €500,000 for operating companies that did not comply with law enforcement agencies.

Tristan Bruns, LWLcom, asked if there were NetFlow or sFlow export obligations for IXes.

Alexander said that, for example, MSK-IX must comply with regulations and store traffic for three months. But they had a large amount of data, five terabits of traffic per second, and did not say how they were able to store it. There was corruption in Russia among officials and networking professionals.

Vasilis Ververis also asked how they blocked VPNs in Russia, whether through IP/port blocking, DPI or something else. Alexander replied that they used sovereign Internet legislation as well as technical means, such as DPI boxes installed on state accounts and filtering traffic through traditional landline operators.

Alexander then posed questions to the audience, which included asking how root server operators such as the RIPE NCC would operate in Russia, but said he did not need an immediate answer.

Kaveh Ranjbar, RIPE NCC, said the organisation only provided IANA-assigned root zones. If regulators required something different, they could not go against IANA. If they were pushed to make changes beyond documented requirements, they would not serve the area requesting this. The RIPE community might not want that, but that would then be a discussion for the Working Groups.

B. Revisiting Recommended BGP Route Flap Dampening Configurations

Clemens Mosig, Randy Bush, Cristel Pelsser, Thomas C. Schmidt, Matthias Wählisch – Freie University Berlin, Internet Initiative Japan & Arrcus, Inc, Université de Strasbourg, HAW Hamburg

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/16-RIPE-83-RFD-Config.pdf

Clemens Mosig presented a joint research project that raised the question of whether there was a need for new BGP Route Flap Dampening configurations. The researchers had found that many vendors only used default configurations that were frequently harmful. Clemens said the team reviewed the old RIPE recommendations for these configurations and found them useful, but in need of an update. The researchers ran a new study that included IPv6, among other changes, and assessed factors such as the suppress threshold for BGP updates and the duration of the suppression for those thresholds. In response to whether new BGP RFD configurations were needed, they stated they were not and should still be used over default configurations.

There were no questions.

C.  minRTT: Mapping Networks With RIPE Atlas

Emile Aben, RIPE NCC

The presentation is available at: https://ripe83.ripe.net/wp-content/uploads/presentations/22-2021-11.ripe83.minrtt.pdf

Emile and his fellow researchers measured latency into networks. One challenge for this process was the spotty coverage of geolocation information about networks. To solve this problem, the researchers turned to RIPE Atlas to augment their geolocation methods. Using the geographical data of Atlas probes and the latency information these probes provided, they were able to determine the minimum latency into a network from a particular location. They also used data from IXP peering LANs and probe neighbourhoods. While RIPE Atlas proved a useful tool, there were some drawbacks, such as being limited to where RIPE Atlas probes were deployed and being inhibited by ICMP blocking and RTT lies. Emile considered future avenues for this research and invited others to consider doing their own research in this area.

Erik Bais, A2B Internet, asked if it was possible to plot Tor-hosted items and then be able to guess where certain devices were located. Emile responded that they grouped information by ASNs or IX IDs and that he did not see applicability for Tor-hosted items.

Vasilis Ververis, Magma Guide,  asked if Emile knew of any ISPs that consistently reported RTT lies. Emile said he did not. RTT lies tended to be at hop one or two and could be due to CPE or intercept boxes.

Christian Bretterhofer, Andritz AG, shared a link to an error when attempting to fetch a resource on RIPE Atlas. He asked what was needed to access the site. Emile said this error should not be happening and invited Christian to reach out to him on SpatialChat.

Plenary, Monday, 22 Nov, 16:00 – 17:00

Monday, 22 November 16:00 - 17:00 (UTC+1)
Chaired By: Wolfgang Tremmel, Alexander Azimov
Scribe: Karla Liddle-White
Status: Draft

A. Insights from Operating an IP Exchange Provider

Andra Lutu

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/21-ripe83_2021_short_v1.3.pdf

Andra Lutu presented insights from an analysis on operating an IP Exchange Provider (IPX). She presented signalling data sets, traffic patterns and international mobility patterns. It was the first detailed analysis of operations in a large IPX which is part of a network composed of 29 IPXs peering using three exchange points and interconnecting around 800 mobile network operators (MNOs) worldwide.

Daniel Karrenberg, RIPE NCC, asked about the synchronised behaviour of clients, whether it was synchronised to the wall clock (UTC).

Andra thanked Daniel for his question and said that they were synchronised to request the data connection around midnight everyday so that is where they observed the peak.

Eliot Lear, Cisco Systems, noted that smart meters and roaming was interesting and whether it was an aggregation provider with some sort of agreed APN with multiple providers.

Andra confirmed that they did see global providers essentially aggregating services across the world and offering a global sim that depended on the roaming function. She said they used the IPXP to leverage the agreement so they did not have to go into each country and negotiate an agreement, they could piggyback on the IPXP’s already existing agreements and deploy their services worldwide.

B. Any Eyeballs - Utilising Happy Eyeballs for Load Balancing

Max Franke, TU Berlin

 The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/13-AnyEyeballs.pdf

Max presented new ways to use Happy Eyeballs for load balancing by using existing code to establish fine grain balancing control. He talked about the ways in which Happy Eyeballs can be utilised from a server point of view, advantages and disadvantages as well as a test implementation using Anycast.

Radek Zajic, DaLuNET.cz, noted that happy Eyeballs was not everywhere and suggested not to go down this path if possible because it assumed Happy Eyeballs would take over and process the rejects but he added that if it was an API client for example, there would be no happy eyeballs. He advised on being very careful about the idea and to research the targeted audience. He continued to say that Happy Eyeballs was created when the market was afraid that IPv6 was not reliable enough ten years ago and effectively it was hiding problems in IPv6 and IPv4 networks and that the community should be targeting its removal eventually rather than keeping it alive and using it for client-side decision making.

Peter van Dijk, PowerDNS, said that Max mentioned many clients were happy with this and asked whether he had also found clients that were not happy.

Max said that he had completed a large background study on the state of happy eyeballs and surprisingly there were still many eyeball implementations being added and many programming languages were still adding it. He said that you could see the quality of the implementation differs, for example, the Apple ecosystem had the closest spec to happy eyeballs and that the one in Chrome was somewhat barebones, but it worked. He said that they tried it with a number of different browsers, and it worked for all of them, on mobile and on desktop operating systems and that there would be some corner cases where it’s not supported but from what he could see it worked with all browsers.  

C. RPKI-Based Policy Without Route Refresh

Randy Bush, IIJ Research and Arrcus Inc.

Randy presented the downsides of dropping Invalids when running BGP Route Origin Validation and offered three solutions to this problem; keep a full adj-RIB-In, if there was no adj-RIB-In then keep the path but mark it as dead or don’t run RPKI policy on any router that could not perform the first two solutions.

Job Snijders, Fastly, asked if Randy knew which OSS/COTS BGP implementations did not have an Adj-RIB-In enabled by default.

Randy replied that as he did not know all implementations, he could not currently answer the question. He said that one of the occasionally popular vendors has it off by default but if he wanted to see something really novel take a look at BIRD.

Wolfgang Tremmel noted that memory had become so cheap and asked why he thought router vendors simply did not use a kind of SSD to cache that information and use that instead of requesting the neighbour to resend everything.

Randy said that if he shipped IOS XR, he couldn’t suddenly change the default because millions of customers would not have it hard configured in their configuration will upgrade their router software and everything changes so he couldn’t ship the fix to turn on adj-RIB-In.

Carlos Martinez, LACNIC, asked whether the presence or absence of Adj-RIB-In had anything to do with what some vendors called soft reconfiguration.

Randy said yes, Cisco by default ships no Adj-RIB-In so if you wanted to turn it on, it’s called soft input, it’s not output also, that would be different.

There were no further questions.

Closing Plenary, Friday, 26 Nov, 10:30-11:30 and 11:30-12:00

Brian Nisbet, RIPE Meeting Programme Committee Vice-Chair, announced that the two open spots of the programme committee would continue to be filled by existing members Dmitry Kohmanyuk and Alexander Azimov, and that there were no other candidates. He said he was happy to have them continue but hoped that more people would step forward next time to support the committee.

A. DNS “Openness”

Geoff Huston, APNIC

This presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/81-2021-11-26-ripe83-dns-openness.pdf

Geoff Huston, APNIC, made a case for why the Internet is all about the DNS these days and why it’s therefore so important to look at the “openness” of the system. He evaluated the “openness” of the DNS according to several different definitions. While it may not be a problem that the system is not the same for everyone, everywhere, he argued that it is a huge problem that the DNS is open in the sense of being able to look up queries and answers in real time. He also argued that DNSSEC is a market failure. He concluded that, for now, the DNS is open – but that, in the near future, it probably won’t be. Markets have taken over from the people behind the original DNS, he said, and the basic principles are breaking down as a few massive companies have essentially taken over the DNS space.

Lars-Johan Liman, Netnod, said that Geoff was probably right and argued that none of the fundamental pillars of the Internet was designed with a market-driven environment in mind. Geoff said that when we deregulated the “monster of telephony” the Internet was supposed to represent deregulation and competition, but that 20 years later, it’s not what was originally envisioned. He added that it’s difficult to make deregulated markets work at the scale of the Internet, and that the debate today is ahead of our social institutions. He said that monsters like General Electric and JP Morgan were created during the industrial revolution in the 1880s that we then spent decades tried to take apart because they got too big too fast, and that history is repeating itself.

Daniel Karrenberg, speaking as the “Guild of RIR Chief Scientists”, asked if the Internet that was dreamt of did not in fact exist, just as a much small subset of the whole. Geoff said that if a business is largely dependent on last-mile access then they’re just not incentivised to spend resources on the larger Internet, including routing and the “difficult bits”. He said that leaving these issues to the giant companies is what’s happening today and we’re moving towards access-only ISPs and customers. He said that he didn’t share Daniel’s optimism.

Vesna Manojlovic, asking as a “cyber citizen”, asked about using Elinor Ostrom’s “governing the commons” principles to keep the future Internet/DNS open. Geoff replied that the rush of industrialisation in America produced a slew of incredibly wealthy profiters who created companies that are still in existence today, and that the giants of today, such as Apple and Google, are building their own vision for the future and setting themselves up for a century of domination. He said that today’s attempts at regulation are extremely ineffective and that we’re still struggling to even figure out how to grapple with the issues. For example, he said, when Google controls 92% of all searches all around the planet, what effect is this one private company having on our language and our thinking? He said that the Internet has scaled by a factor of ten billion, which is an amazing achievement, but that we haven’t spent time understanding the consequences. He said he’s at a loss as to how to change things.

Blake Willis, Zayo Europe, asked whether DNSSEC works better over IPv6 since fragmentation and firewalling are less awful than IPv4. Geoff responded that it’s not an IPv4/IPv6 issue but an economic issue. He said that no one is motivated to do DNSSEC and that there are no tools to do things yourself if you don’t trust the DNS.

Vesna Manojlovic, speaking as a “parent of young people”, asked whether Geoff had hope that younger generations will be able to solve these problems. Geoff said that it will take a long time to figure out what to do with the monster we’ve created. He disparaged EU efforts to build a government resolver as a competitor to Google, for example, and said that it won’t be solved in one generation. He said a big part of the issue is the balance between private/public and that we’ve tipped too far into the private realm. He encouraged the RIPE community to work on public sector projects and for governments.

Dmitry Kohmanyuk, UA ccTLD, asked whether, “in the brave new world (or maybe franchised privatised world)”, whether DNS compartments might exist that don’t communicate with one another, or whether DNS could be used to bridge islands. Geoff responded that it will all separate with no bridging, just like in the 1980s. He said that cooperation is not valued in such a competitive market, and that even issues like privacy come down to wanting to protect competitive advantage, rather than personal rights.

Raymond Jetten, speaking as himself, asked whether people use Google because their ISPs’ DNS servers are regulated and modified, or because of the level of DNS quality provided. Geoff said that he’s looked into this a lot and that most people use Google because their ISPs send their queries to Google because it’s cheaper for them than any other solution.

Alex Le Heux, Tucows, asked whether Geoff believed we’re in trouble because we never solved the monopoly power dynamics that emerged from the industrial revolution. Geoff responded that the US tried to bring in some anti-trust regulation in the early part of the 20^th century that resulted in a massive depression and that Congress got scared, and that Ford and GM then earned the country so much money that no one was prepared to touch them. He said that part of the problem today is that taking on such giants seems to lead to self-harm, and requires careful and informed discussion in our societies about how to deal with technology. He said that when this kind of discussion is pushed to the edges, such as happens at the IGF, then we’ll never make progress.

The session chairs closed the queue to any further questions in the interest of time.

B RIPE 83 Technical Report

Menno Schepers, RIPE NCC

This presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/95-RIPE-83-Tech-Report.pdf

Menno Schepers, RIPE NCC, gave an overview of the meeting week from the tech team’s point of view, including some of the small issues that came up and how they were solved. He mentioned that the stenography stream is now IPv6-enabled, which means the RIPE Meeting website is now completely dual-stacked.

Remco van Mook, asked how many other large scale users the Meetecho platform has, as the bugs seem pretty generic. Menno responded that he knew that Meetecho was also working with the IETF. He added that some issues only popped up one week before the meeting because of browser updates (for example) and that it made it hard to spot them.

Black Willis, Zayo, thanked Menno for his efforts and said that he would like a RIPE NCC Access 2FA option that doesn’t require a mobile app. Menno took that comment on board.

Brian Nisbet said that he’s participated in a lot of online meetings but that the RIPE Meetings are by far the smoothest.

Robert Scheck asked whether there are bandwidth statistics for Meetecho, too. Menno said that there probably are but that he didn’t have them available at the time.

Brian thanked everyone for submitting their talks to the plenary and asked everyone to rate the talks they saw so that the RIPE Meeting Programme Committee can make future selections based on that feedback. He then closed the session expressing his hope that RIPE 84 would be a hybrid meeting.

C. Closing Plenary

Mirjam Kühne, RIPE NCC

This presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/96-RIPE-83-Closing-Plenary-.pdf

RIPE Chair Mirjam Kühne gave an overview of some meeting statistics. There were 1,126 registered participants in total, including 240 newcomers with an average of 450 participants per day.

She thanked outgoing chairs Alireza Vaziri of Anti-Abuse and David Knight of DNS, and welcomed newly or re-elected chairs Bijal Sanghani of RIPE NCC Services, Achilleas Kemos and Johan Helsingius of Cooperation, Marcos Sanz of Open Source and Moritz Müller of DNS.

She also thanked outgoing RIPE Meeting Programme Committee member Pavel Lunin and welcomed re-elected members Alexander Azimov and Dmitry Kohmanyuk.

Finally, she thanked outgoing NRO NC representative Nurani Nimpuno and welcomed the newly elected representative Sander Steffann.

She announced winners from the various quizzes throughout the week, thanked the meeting sponsors and asked for meeting feedback from all those in attendance. She closed the meeting by expressing her hope to see everyone in Berlin.