Marco Hogewoning

“Hi Marco Thank you for your comments. With regards the EU Commission's DNS4EU initiative, there is no direct link between this and the European Resolver Policy, the latter of which comes from industry. However, it is entirely possible (and desirable in my view) that the DNS4EU initiative may specify that resolvers should adopt and be compliant with the policy in order to meet the criteria that you have quoted in your message. Would this have the support of RIPE? This is certainly a point that could be raised during the Commission's next HLIG meeting. Andrew”

Thanks for that insight. To be clear, RIPE NCC can't speak for or on behalf of RIPE unless there is an explicit position from the community which allows us to do so. In relation to your question on whether RIPE would support such a position, probably best to defer this to the DNS or Cooperation Working Group. Of course as RIPE NCC, we're happy to help communicate and distribute such a position. But we would need guidance from the community on the merits of your suggestion first.

Hey Andrew, Thanks for this, appreciate the efforts here. What I was wondering, is there a direct link with the DNS4EU initiative as it was presented in the EU's Cybersecurity Strategy that was published late 2020, quoting from the document (JOIN/2020/18): "With a view to reducing security issues related to market concentration, the Commission will encourage relevant stakeholders including EU companies, Internet Service Providers and browser vendors to adopt a DNS resolution diversification strategy. The Commission also intends to contribute to secure Internet connectivity by supporting the development of a public European DNS resolver service. This ‘DNS4EU’ initiative will offer an alternative, European service for accessing the global Internet. DNS4EU will be transparent, conform to the latest security, data protection and privacy by design and by default standards and rules and form part of the European Industrial Alliance for Data and Cloud". Is this initiative seeking to be an implementation of this or could it be? Thanks, MarcoH (Manager Public Policy and Internet Governance, RIPE NCC)

“What about IPv6+?”

I haven't gotten much details on "IPv6+" outside of a recent press release. The addressing components of New IP seem to go under different names and there are a number of different approaches contained the the various presentations and documents about New IP. As mentioned in the article above, when IPv6 was first designed people thought it could have a more hierarchical structure that would have tied in with the routing structure of the Internet at the time. But as the market gradually moved away from that hierarchical model, the address allocation system evolved in what it is today. Which allows for much. more direct traffic exchange between operators, independent of the addressing structure. The proven concept here is that addressing follows the network structures as the market deploys them, the IP address in the end is the demarkation point of where a particular node attaches to the network. This is why they often change when you change to another network or location. That is a feature, not a bug. Over time there have been many proposals to take a different approach and either use a more fixed structure where addresses get a meaning or are envisioned to be more permanent. But none of these proposals appear to provide the scalability required or other wise provide enough of an improvement for the market to embrace those solutions and adopt them. Which is why we advocate for these ideas to be developed bottom up and in an open discussion, where all stakeholders can talk about and evaluate the pros and cons of such proposals and where the market can ultimately pick those solutions that best answer to their needs.

“Very interesting post. Where can I find more information about your " IXP Country Jedi". Is the visualisation based on from/to all Atlas probes in a country (i.e., all possible pairs), for example NL? How did you infer the IX? How did you infer transit and end-users? I would be glad to further contribute with it, I just need to understand a bit more.”

Hi Jair, There is actually a lot more information about IXP Country Jedi on this website, for instance here https://labs.ripe.net/playground/ixp-country-jedi/ixp-country-jedi, which will also guide you to the interfaces you can use to retrieve information about a particular country. Please keep in mind that this tool is still being refined and further developed, things might not always be complete or change over time. There is also a dependency on having RIPE Atlas probes in a particular country and its networks to do the measurements required, so the actual results vary per country based on probe availability.

“Saying that automatic contracts ("smart contracts" is the marketing BS) cannot be changed ("these contracts are unmodifiable") is not strictly true. To quote an old saying "every problem in computer science can be solved with one more indirection". So, you can have a pointer to the current version of the code of the smart contract, and changing the code by adding a new version of the pointer. Of course, this adds complexities and security risks but it shows that there are ways to modify automatic contracts, for instance to follow a change in policies. The description of the "51 % attack" is very sketchy ("quickly spawning a large quantity of client nodes that participate in the consensus making"). In a real blockchain, techniques like proof-of-work and proof-of-stake prevent this trivial Sybil attack. But there is a subtler reason why the "51 % attack" is overhyped: it is easily detectable (the Bitcoin Core code, for instance, logs it). So, honest miners will see it. It will not be easy to recover from the attack (the honest miners will have to fork) but it cannot be stealthy.”

Hey Stéphane, As the text suggests, for many issues a work around might be available. The key point is that while a work around (in theory) might exist, the question is whether such a work around would actually still deliver on the promise and the additional complexity would be worth it. As for the 50%+1, it was mostly for illustration, as you rightfully point out that is the most simple attack and it is relatively easy to detect. However, as you also note, the fact that you can easily detect it does not automatically imply a roll back of the offending transaction is easy as well. I am sure we haven't covered every possible attack or remedy, but in discussing whether blockchain is a suitable addition to the registry system, we should certainly take a very good look at all the attack vectors and the numerous examples that are around where such attacks have been successfully executed against a blockchain.