KeyTrap
• 12 min read
Just how ‘devastating’ is the KeyTrap vulnerability? How does it work, and why the dramatic response?
Articles
Likes on articles
Geoff Huston AM is the Chief Scientist at APNIC, where he undertakes research on topics associated with Internet infrastructure, IP technologies, and address distribution policies. From 1995 to 2005, Geoff was the Chief Internet Scientist at Telstra, where he provided a leading role in the construction and further development of Telstra's Internet service offerings, both in Australia and as part of Telstra's global operations. Prior to Telstra, Mr Huston worked at the Australian National University, where he led the initial construction of the Internet in Australia in the late 1980s as the Technical Manager of the Australian Academic and Research Network. He has authored a number of books dealing with IP technology, as well as numerous papers and columns. He was a member of the Internet Architecture Board from 1999 until 2005 and served as its Executive Director from 2001 to 2005. He is an active member of the Internet Engineering Task Force, where he currently chairs two Working Groups. He served on the Board of Trustees of the Internet Society from 1992 until 2001 and served a term as Chair of the Board in 1999. He has served on the Board of the Public Internet Registry and also on the Executive Council of APNIC. He chaired the Internet Engineering and Planning Group from 1992 until 2005.
Website: http://www.potaroo.net/
• 12 min read
Just how ‘devastating’ is the KeyTrap vulnerability? How does it work, and why the dramatic response?
• 13 min read
There are five RPKI Trust Anchors, one for each RIR. But if one of these trusted operators were coerced into falsely issuing a certificate, there's no way relying parties could avoid being misled. Geoff Huston talks about the adopted approach to RPKI Trust Anchors and how things might be improved.
• 21 min read
Centrality and fragmentation appear to be two completely opposite problems - and yet today's Internet seems to be in danger of both at the same time. In this guest post, Geoff Huston shares his views on this apparently contradictory state of affairs.
• 16 min read
One way or another, the users of the Internet pay for the Internet. But this doesn't stop various players in the space jostling for relative advantage, claiming others should be paying more while they pay less. Geoff Huston explores the ways this tension is reflected between carriage providers and …
• 52 min read
Is the DNS open? And would its being open count as a strength or a weakness? These questions lie at the heart of discussions about the future of the Internet, but to answer them, first you have to ask what 'openness' amounts to when it comes to DNS.
• 20 min read
Why did a network technology such as the Internet, designed to pass control away from the central network to the connected devices, succumb to the level of centrality we see today? In this guest post, Geoff Huston shares his thoughts on the topic of centrality.
• 48 min read
In this article I talk about consolidation, the fact that more and more data traffic goes ‘dark’ and the importance of open measurement platforms and open data sets. We need public measurements that are impartial, accurate, comprehensive and of course unbiased as an essential precondition for the f…
• 12 min read
Computers have always had clocks. Well maybe not clocks as you might think, but digital computers have always had oscillators, and if you hook the oscillator to a simple counter then you have a clock.
• 21 min read
A panel session has been scheduled at the forthcoming Internet Governance Forum (IGF) in Paris in November that speaks to the topic that Internet Governance is on a path to irrelevance. What's this all about?
• 14 min read
If you had the opportunity to re-imagine the DNS, what might it look like? Normally this would be an idle topic of speculation over a beer or two, but maybe there’s a little more to the question these days. We are walking into an entirely new world of the DNS when we start to think about what exact…
There have been some refinements to BBR (see https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00) that appear to make it a more socially friendly flow control protocol. So if the RedHat release uses BBRv2 then its possible that you will see a protocol that attempts to balance its network pressures with those of loss-based protocols in a fairer manner.
“Hi Geoff, I already seen your presentation in APRICOT 2017 ( slide and youtube ) Can you tell me how to check the most active ipv6 prefixes for the last day,week or month? Thanks in advance,”
Thanks for your question. For IPv4 prefixes: http://bgpupdates.potaroo.net/instability/bgpupd.html For IPv6 it's: http://bgpupdates.potaroo.net/instability/v6-bgpupd.html Thee reports are updated every 24 hours
No, things have not changed tremendously. In fact, not much has changed at all over the past three years from the data set I have, so I'm unsure what data you have used to form that observation. Today, the overall use of Google's PDNS service in the Internet spans some 14% of the total user population. See http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=1&q=0 The level of use of this service is highest in Western, Middle and Eastern Africa, Oceania and Southern Africa. The lowest levels of use are found in western and northern Europe, East Asia, and Australia and New Zealand. (see the country table at the URL given above)
Hi Todd, It's always difficult to say what happened from a distance and probably only Dyn (or presumably the attackers) have direct knowledge of what happened and the rest of use can only speculate. It appears to be a pretty safe assumption that Mirai was used, and the source code of Mirai contains a smorgasbord of potential attacks, of which generating DNS queries is just one. So two weeks later it looks like its reasonable to assume that the attack contained a notable DNS component. More to the point, I was wondering if we could use the DNS (and potentially DNSSEC) to protect itself from DNS-based attack incidents and, if so, how we could do so.
Showing 4 comment(s)