Background and Motivation
Routing security has been a critical focus due to the vulnerability of BGP (Border Gateway Protocol), which traditionally lacks built-in authentication. This weakness has led to frequent BGP route hijacks and leaks, where malicious or misconfigured announcements redirect traffic. Recent years have seen a push for cryptographic route validation. The Resource Public Key Infrastructure (RPKI) allows IP prefix owners to publish authorizations (ROAs) for valid origin ASes. Adoption of RPKI has grown steadily – by late 2023, about 48.2% of IPv4 prefixes were covered by RPKI origin records. This improves protection against route hijacks, as many networks now reject BGP announcements that are RPKI-invalid (i.e., unauthorized origin). However, studies also find inconsistent deployment: some ISPs enforce origin validation for most routes but still accept invalid routes from their customers (presumably to avoid losing revenue), undermining security. Beyond origin authentication, BGPsec was introduced for path validation, but it has seen little deployment due to complexity. Instead, the community has rallied around best practices like filtering and the MANRS initiative (Mutually Agreed Norms for Routing Security).
High-profile incidents underscore the stakes. In June 2019, a small US ISP accidentally leaked routes that misdirected a huge volume of traffic, causing a major Cloudflare outage. Such incidents are not rare – on the contrary, the Internet experiences thousands of BGP routing incidents each year, including both accidental leaks and deliberate hijacks. In 2020 alone, over 3,000 route leaks and hijacks were reported globally. Because BGP hijacks can facilitate man-in-the-middle attacks (e.g., redirecting users to impostor sites to steal credentials), improving inter-domain routing security is viewed as urgent. Researchers have proposed new architectures like SCION (a clean-slate secure Internet architecture) to address BGP's fundamental trust issues. SCION provides route control and transparency – senders can select paths and avoid untrusted networks, and receivers can verify that the path wasn't tampered with. This "trust but verify" approach means an attacker could only hijack traffic if they physically lie on the chosen path, significantly reducing hijack risk. SCION has been prototyped and even deployed in academic testbeds, signaling a notable research direction beyond patching BGP.
Practical implications: The progress in routing security research has translated into a mix of incremental and architectural changes. Incrementally, many network operators are now deploying RPKI/Route Origin Validation (with major CDNs and ISPs enabling it, leading to over 50% of prefixes covered). This helps prevent the simplest hijacks (involving fake origins). Yet, partial adoption means attackers can still exploit the remaining unsecured half of the global routing table. Industry collaborations (like MANRS) encourage broader adoption of filtering and RPKI to close these gaps. For real-time detection, services like BGPStream share live alerts of suspicious BGP events so operators can quickly mitigate ongoing hijacks (e.g., by dropping routes). In the longer term, the community is watching solutions like SCION that could fundamentally redesign inter-domain routing security. While SCION isn't broadly deployed yet, it represents a notable research-driven vision: an Internet where operators and even end-users have cryptographic assurances on path integrity. This could drastically reduce incidents, but it requires significant coordination and infrastructure change. In summary, today's Internet is moving from completely trust-based routing to a more trust-but-verify model, combining near-term measures (RPKI, filtering) with exploration of new secure routing paradigms.
LEO constellations (like SpaceX Starlink) form a rapidly moving network topology, which introduces unique routing challenges. Traditional protocols struggle – for example, a recent analysis noted that BGP would "hardly converge" in a fast-changing LEO topology due to constant link changes (satellites entering/leaving view). Frequent updates (sometimes every few minutes as satellites pass overhead) would lead to route instability, loops, or blackholes if using vanilla BGP. This means LEO networks will likely require custom or enhanced routing protocols that can handle predictably dynamic connectivity (e.g., scheduled handovers). From a security standpoint, any routing protocol in satellites must still guard against false announcements or control messages – possibly even more so, since a malicious actor compromising a satellite or ground station could inject bad routes affecting a wide region. Techniques from terrestrial routing security can help here. For instance, origin authentication (RPKI) is equally applicable: satellite ISPs exchanging routes with terrestrial networks should use RPKI to prevent hijacks at the ground interconnects (ensuring no bogus prefix announcements are accepted from or propagated into the satellite system). Within the constellation's internal routing, BGP itself may be replaced by a centralized SDN controller or a variant of link-state routing with predictive algorithms. In either case, authentication of routing updates is critical – if satellites use a link-state protocol, they'll need a mechanism to sign/verify updates to avoid spoofed topology data. A lesson from BGPsec could apply: use of cryptographic signatures on path announcements (or even a lightweight symmetric authentication scheme given the closed system).
Notably, LEO networks might benefit from path-aware secure routing architectures like SCION. Since satellites form their own AS-level network, a SCION-like approach could allow ground stations and satellites to agree on specific path segments (e.g., through particular satellite hops) that are verifiably secure. The idea of senders determining and cryptographically locking in the route could mitigate certain attacks – an adversary would have to physically be on the chosen path to alter it. This could be valuable if, say, multiple countries operate LEO constellations: one could avoid routing traffic through a rival's satellites. Inter-satellite links (ISLs) also open the door to multipath routing (discussed later) – but from a security angle, having multiple route options means the network could quickly route around suspicious nodes if one satellite is compromised or misbehaving. In summary, LEO networks must fuse routing flexibility with security. They should adopt the best practices of terrestrial routing security (RPKI, filtering of invalid routes, etc.) at their peering points, and internally they likely need new protocols. Any new satellite routing protocol should incorporate authentication from the start, given the high stakes of a potential in-orbit route hijack. The dynamism of LEO constellations also makes a strong case for more automated, perhaps centrally coordinated, routing – which, if done, implies trust in the central controller's security. Robustness might entail distributing trust or using threshold signatures so no single compromised controller or station can wreak havoc. This remains an open research and engineering challenge: designing a routing system for LEO that is both agile and secure.
For detailed information about expected outcomes, requirements, and related work for this thesis topic, please contact Dr. Nitinder Mohan at n.mohan@tudelft.nl.
