This report explains how the outage of a single AS can affect the connectivity of the impacted region with the rest of the world, especially when it is the dominant ISP on the market. Internet connectivity at the network level is driven by interaction between autonomous systems (AS’s). As the number of alternate routes between AS’s increases, so goes the fault-resistance and stability of the internet across the network. Although some paths inevitably become more important than others, establishing as many alternate routes as possible is the only viable way to ensure an adequately robust system.

The global connectivity of any AS, regardless of whether it is a minor provider or an international giant, depends on the quantity and quality of its paths to Tier-1 ISPs. Usually, Tier-1 implies an international company offering global IP transit service over connections to other Tier-1 providers. But there is no guarantee that such connectivity will be maintained. Only the market can motivate them to peer with other Tier-1’s to deliver the highest quality service. Is that enough? We explore this question in the IPv6 section below. For many ISPs at all levels, losing connection to just one Tier-1 peer would likely render them unreachable in some parts of the world.
 

Measuring Internet Reliability

Let’s examine a case where an AS experiences significant network degradation. We want to answer the following question: “How many AS’s in the region would lose connectivity with Tier-1 operators and their global availability along with it?”

For those of you still now subscribed to the Cybersecurity Newsletter - the form is at the top of the page.

Best news, articles and scientific papers published since August 12 till 18 are below.

TL;DR: Client-server architecture of our internal configuration management tool, QControl. 
At its basement, there’s a two-layered transport protocol working with gzip-compressed messages without decompression between endpoints. Distributed routers and endpoints receive the configuration updates, and the protocol itself makes it possible to install intermediary localized relays. It is based on a differential backup (“recent-stable,” explained further) design and employs JMESpath query language and Jinja templating for configuration rendering.

Qrator Labs operates on and maintains a globally distributed mitigation network. Our network is anycast, based on announcing our subnets via BGP. Being a BGP anycast network physically located in several regions across the Earth makes it possible for us to process and filter illegitimate traffic closer to the Internet backbone — Tier-1 operators.

On the other hand, being a geographically distributed network bears its difficulties. Communication between the network points-of-presence (PoP) is essential for a security provider to have a coherent configuration for all network nodes and update it in a timely and cohesive manner. So to provide the best possible service for customers, we had to find a way to synchronize the configuration data between different continents reliably.

In the beginning, there was the Word… which quickly became communication protocol in need of an upgrade.

This post represents a regular Cybersecurity Newsletter issue, available at the dedicated subscribe page.

This time, we are between August 5 and 11 with the best articles, blog posts, and preprints.

This blogpost represents a regular Cybersecurity Newsletter issue, available at the dedicated subscribe page.

This time, we're between July 29 and August 3 with the best articles posted.

Today we often talk about SLA and redundancy. And the increasing role of clouds in the overall Internet infrastructure. Someone says that they will play a crucial role in traffic share in the nearest future. However, there are other huge ISPs - Tier-1, aka the biggest transit operators, which have transnational cables and indeed are part of the historical Internet backbone. They often play the role of last resort in the filtration process of bad routes. Because they have hundreds of customers. Also, almost all of these customers believe in what they got from the provider ISPs. That is the main reason why modern internet drafts rely on Tier-1s as flag carriers and hope that they’ll apply a new security mechanism among all the others.

Is this always a real scenario?

TL;DR: starting February 2020, DNS servers that don’t support DNS both over UDP and TCP may stop working.

Bangkok, in general, is a strange place to stay. Of course, it is warm there, rather cheap and some might find the cuisine interesting, along with the fact that about half of the world’s population does not need to apply for a visa in advance to get there. However, you still need to get acquainted with the smells, and the city streets are casting cyberpunk scenes more than anything else.

In particular, a photo to the left has been taken not far from the center of Thailand’ capital city, one street away from the Shangri-La hotel, where the 30th DNS-OARC organization meeting took place on May 12 and 13. It is a non-profit organization dedicated to security, stability, and overall development of the DNS — the Domain Name System.

Slides from the DNS-OARC 30 meeting are recommended for everyone interested in how the DNS works, though perhaps the most interesting is what is absent in those slides. Namely, a 45-minute round table with a discussion around the results of DNS Flag Day 2019, which occurred on February, 1, 2019.

And, the most impressive result of a round table is the decision to repeat DNS Flag Day once again.

Two days ago, May 5 of the year 2019 we saw a peculiar BGP outage, affecting autonomous systems in the customer cone of one very specific AS with the number 721.

Right at the beginning, we need to outline a couple of details for our readers:
 

1. All Autonomous System Numbers under 1000 are called “lower ASNs,” as they are the first autonomous systems on the Internet, registered by IANA in the early days (the late 80’s) of the global network. Today they mostly represent government departments and organizations, that were somehow involved in Internet research and creation in 70-90s.
2. Our readers should remember, that the Internet became public only after the United States’ Department of Defense, which funded the initial ARPANET, handed it over to the Defense Communication Agency and, later in 1981, connected it to the CSNET with the TCP (RFC675)/IP (RFC791) over X.25. A couple of years later, in 1986, NSF swapped the CSNET in favor of NSFNET, which grew so fast it made possible ARPANET decommission by 1990.
3. IANA was established in 1988, and supposedly at that time, existing ASNs were registered by the RIRs. It is no surprise that the organization that funded the initial research and creation of the ARPANET, further transferring it to another department because of its operational size and growth, only after diversifying it into 4 different networks (Wiki mentions MILNET, NIPRNET, SIPRNET and JWICS, above which the military-only NIPRNET did not have controlled security gateways to the public Internet.

As we wrote in the 2018-2019 Interconnected Networks Issues and Availability Report at the beginning of this year, TLS 1.3 arrival is inevitable. Some time ago we successfully deployed the 1.3 version of the Transport Layer Security protocol. After gathering and analyzing the data, we are now ready to highlight the most exciting parts of this transition.

As IETF TLS Working Group Chairs wrote in the article:
“In short, TLS 1.3 is poised to provide a foundation for a more secure and efficient Internet over the next 20 years and beyond.” 

TLS 1.3 has arrived after 10 years of development. Qrator Labs, as well as the IT industry overall, watched the development process closely from the initial draft through each of the 28 versions while a balanced and manageable protocol was maturing that we are ready to support in 2019. The support is already evident among the market, and we want to keep pace in implementing this robust, proven security protocol.

Eric Rescorla, the lone author of TLS 1.3 and the Firefox CTO, told The Register that:
“It's a drop-in replacement for TLS 1.2, uses the same keys and certificates, and clients and servers can automatically negotiate TLS 1.3 when they both support it,” he said. “There's pretty good library support already, and Chrome and Firefox both have TLS 1.3 on by default.”