Starlink Falklands Islands Internet Traffic and Argentina: The Facts

A typical data centre where Points of Presence (PoPs) are hosted
(Photo Source: datacenterfrontier.com)

This is the final post in a three-part follow-up series covering the presentations delivered by Sure Falkland Islands on March 19th, 2025, in Stanley. You can listen to the public presentation and view the accompanying slides here.

In a previous OpenFalklands post, I examined the technical aspects discussed during the meeting – specifically, the comparison of Starlink and OneWeb’s technical performance in the Falkland Islands. In the second post, I addressed Sure’s assertion that they would not turn a profit if Starlink were allowed to operate in the Falklands.

In this final post, I focus on one particular claim made during the presentation: that 20% of Falkland Islands Starlink traffic lands in Argentina, presented as a drawback of Starlink’s service compared to Sure’s proposed OneWeb LEO service.

Let me be clear up front: in my opinion, from a technical standpoint, routing some traffic through Argentina poses no significant issues and should not be considered a dealbreaker for Starlink’s adoption in the Falklands.

For readers not interested in the technical details, feel free to skip ahead to the conclusions at the end of the post.

Presentation comments

These were some of the comments made in the presentation.

“Importantly as well, the [Ed: OneWeb] traffic doesn’t route through Argentina.”

“The point of what we were saying about that is that does everyone in the Falkland Islands want to rely on a service where [Ed: 20% of] the traffic does go through Argentina.”

“The point of what we were saying about that is that does everyone in the Falkland Islands want to rely on a service where the traffic does go through Argentina…   …if that’s what you as a community say that you’re not bothered about, then we would [say] we’re listening to you and we would become a reseller of Starlink. Sorry that’s just completely completely wrong”

Starlink’s terrestrial infrastructure

Two Starlink terrestrial infrastructure components are relevant to this discussion: Ground Stations and Points of Presence.

Ground Stations

Ground stations are terrestrial-based facilities that communicate directly with Starlink satellites in orbit. These stations transmit and receive data to and from the satellites, allowing the Starlink system to provide internet service to users. Ground stations are equipped with large antennas that can communicate with the Starlink satellites, enabling them to exchange data such as Internet traffic, user requests, and system status updates. As the satellites orbit the Earth, they continuously communicate with the ground stations.

The two relevant ground stations for this discussion are located in Punta Arenas and Buenos Aires.

Points of Presence (PoPs)

Starlink POPs are network hubs where global Internet traffic enters or exits the Starlink terrestrial network, which uses private fibre leased lines to connect to ground stations. OneWeb has similar terrestrial capabilities.

It is important to remember that Ground Stations and PoPs do NOT need to be co-located in the same data centre. In fact, they are far more likely not to aid resilience or due to regulatory issues. However, they may be thousands of miles apart but connected together with a terrestrial high-speed fibreoptic fibre leased line from another company.

It should be remembered that when running a network trace programme to see where IP traffic flows, Only Starlink PoPs can be seen, not Ground Stations.

Location of Starlink PoPs

These are the two PoP locations relevant to this discussion – Santiago, Chile and Buenos Aires, Argentina, although Starlink has many more in South America.

Three of the Starlink PoPs in South America.

Note: For the technically minded, ASN stands for Autonomous System Number which is a unique number assigned to a group of IP networks operated by one or more network operators that share a common routing policy. It’s used in the Border Gateway Protocol, which is responsible for routing internet traffic.

Starlink’s routing of Falkland Island’s Internet traffic

How Starlink routes its traffic on its private terrestrial network is considered commercially confidential by the company, as is the case for all network providers – including OneWeb.

POPs are typically assigned by user location. The most likely path for the Falkland Islands Starlink IP traffic would be for Starlink to use the Punta Arenas Ground Station, with traffic then being routed to their Santiago PoP using the Chile Austral Optical Fibre cable network. From there, European traffic would be routed to the east coast of South America, and one of the transatlantic undersea cables would be used to take the traffic to Europe.

Starlink could also route traffic to Buenos Aires in Argentina. Indeed, in the presentation, Sure claimed that 20% of Falkland Islands IP traffic landed in Argentina. Let’s discuss this contention:

1. Empirically, there have been no indications from any Starlink user – or in testing – in the Falkland Islands that they see traffic routed via an Argentina ground station; all traffic seems to have been routed via the Puntas Arena ground station to Starlink’s PoP in Santiago.
2. The routing path adopted by Starlink for its backhaul traffic is totally under their control, like all ISPs, and they can easily decide to route Falkland Islands traffic to avoid Argentina territory. This is probably the case today but Starlink would never confirm it in public.This is the same approach as adopted by OneWeb/Intelsat to allow Sure Falkland Islands’ Internet traffic to avoid Argentina. Starlink is no different to OneWeb in that respect.
3. As a matter of interest, There are currently no terrestrial trans-Andean terrestrial fibre optic cables directly linking Chile and Argentina other than undersea cables, although there is one is planned for 2026 –  the EdgeUno cable.

Update: Since the publication of this post, it has come to my attention that there are probably many Pan-Andean fibre cables connecting Chile – Argentina – or to Uruguay – but they are not published for security reasons. One published is Texius who has a trans-Andean terrestrial network connecting Valparaiso and Buenos Aires. Another is tiSparkle, which link Santiago and Buenos Aires. I have no idea which cable Starlink is using to link Santiago to backhaul traffic to the East Coast transAtlantic cables.

Telxius’s terrestrial backhaul haul network connecting Chile and Brazil.

Why it’s of no concern if Starlink traffic transits an Argentina network.

There should be no concern about Falkland Islands Internet landing in Argentina due to the end-to-end data encryption of Starlink’s Internet traffic. This is no different to OneWeb’s Intelsat network.

Satellite to Ground Stations

Traffic between the Starlink user terminal (the dish) and the satellite is encrypted. The exact encryption protocols used over the air interface aren’t fully disclosed publicly, but it’s known that Starlink leverages AES-256 encryption is used for securing the communication link. AES-256 is a strong symmetric encryption algorithm widely adopted in military and enterprise contexts.

Terrestrial (Backhaul) Network

Starlink connects with existing fibre and Internet backbone providers for backhauling IP traffic worldwide in its PoPs. Like every other carrier, they rely on standard Internet security protocols (TLS 1.2/1.3) to encrypt traffic, particularly as it transitions to/from the public Internet. TLS 1.3 is particularly strong, using modern cipher suites like AES-128-GCM or ChaCha20-Poly1305 with Perfect Forward Secrecy (PFS).

This level of encryption adopted by Sure (and OneWeb) means that bad actors would not have any meaningful attack vectors. ‘Attack vectors’ refer to the paths or methods that hackers or malicious actors use to gain unauthorized access to a system, network, or device to exploit vulnerabilities.

In my view, Sure’s specific mention of traffic interception because of routing through Argentina is wholly specious and misleading in practice.

In the case of the other threats mentioned that could be caused by Falkland Islands’ Internet traffic landing in Argentina – such as the cyber security attacks and Denial of Service attacks – these concerns are also entirely unfounded and misleading. As many attendees of the presentation rightly pointed out, cyber security attacks and Denial of Service attacks can and often do, originate from anywhere in the world. Specifically, linking their likelihood to Argentina is inappropriate and unsupported.

Conclusions

The concerns raised during the presentation regarding the Falkland Islands’ Internet traffic passing through Argentina are, in my view, overstated and technically unfounded. From a technical and security perspective, these concerns are effectively neutralized by Starlink’s robust end-to-end encryption protocols. These encryption standards, consistent with those employed by all reputable ISPs (including OneWeb), safeguard the confidentiality and integrity of user data, regardless of which terrestrial networks are used for backhaul.

Additionally, it’s worth emphasizing that country routing decisions are entirely under Starlink’s control and can be modified at any time to account for geopolitical considerations or customer preferences. This flexibility is no different from how OneWeb and Intelsat manage their Falkland Islands Internet traffic routes. It’s quite clear that Starlink would route traffic to avoid Argentina when they are permitted to offer service in the islands.

The suggestion that routing traffic through Argentina increases exposure to cyber threats or denial-of-service attacks is similarly misleading. Such threats are inherently global and not confined to specific geographic transit points. There is no technical basis to claim that traffic passing through Argentina introduces any additional security risk.

Ultimately, the focus should remain on delivering quality, resilience, and affordable Internet services to the Falkland Islands, rather than speculative concerns over routing paths that hold no material impact on security or performance.