Continuing our exploration of Web 2.0 vulnerabilities and their impact on the Web3 ecosystem, this article focuses on a particular category of Web2 security incidents with serious implications for the Web3 industry. Central to our investigation are attacks on the Border Gateway Protocol (BGP), a key element of the global Internet's routing infrastructure.

In this piece, we first introduce BGP, how it works, how attackers exploit it to divert funds from Web3 users, followed by a review of existing prevention mechanisms. We then analyze how and why these mechanisms could be circumvented, showcasing two of the most notable incidents: the KlaySwap and the Celer Bridge cases. Further, we propose some potential mitigations and explore ongoing research on how Distributed Ledger Technology (DLT)-based solutions could help address these flaws.

The Border Gateway Protocol Explained

The Border Gateway Protocol acts as the Internet's postal service, directing how information should traverse between different networks to ensure data takes the most efficient route from its origin to its destination. This is achieved through a system where networks, known as autonomous systems (ASes), announce the IP address blocks they can reach. Adjacent networks propagate these announcements, and through this collaborative, iterative process, a map of the Internet's topology is created. However, BGP, designed decades ago, operates largely on trust. Despite the introduction of several security measures to reduce this reliance on trust, BGP assumes all participants provide accurate routing information, adhering to established rules. This inherent trust is where vulnerabilities emerge, most notably through BGP hijacking. In such events, malicious actors announce IP address blocks that don't belong to them, misdirecting data traffic to unauthorized destinations, often with nefarious intent.

To fully understand BGP hijacking, we will travel back to BGP's foundational years. By examining its initial design limitations and tracing the evolution of its security measures with the introduction of the Resource Public Key Infrastructure (RPKI), Route Origin Authorization Records (ROAs), Route Origin Validation (ROV), and BGPSec, we can gain a comprehensive understanding of the present-day challenges and the steps that could be taken to mitigate them.

If you're unfamiliar, see here for a video explanation of the Border Gateway Protocol.

Early Stages

In its original specification, the BGP protocol lacked robust security features, leaving it susceptible to unauthorized manipulation of routing data. In Figure 1, we provide an example of both a legitimate flow and a hijacked one. The left side illustrates a flow for the legitimate path from AS 30 to AS 52. Conversely, the right side depicts an active prefix hijacking attack. During this attack, AS 52 doesn't receive the traffic from AS 30 as intended. This disruption is caused by AS 29, which begins announcing the prefix 139.179.0.0/16, thereby altering the routing table near both AS 30 and AS 10. This malicious action creates a false path, misguiding some internet routes and replacing the authentic path. Consequently, the attacker, AS 29, intercepts the traffic that AS 52 should have received from AS 30 for the prefix 139.179.0.0/16.

Fig1. Prefix Hijacking Attack

Enhancing BGP Security with RPKI, ROAs, and ROV

In response to threats that could undermine the Internet's routing system, industry experts have sought solutions to address these weaknesses.

The Resource Public Key Infrastructure (RPKI) emerged as the initial mitigation effort. Tailored to secure the Internet's routing infrastructure, particularly the BGP, RPKI comprises a decentralized array of repositories that store trust anchors including Route Origin Authorization Records (ROAs) and X.509 certificates.

These anchors play a crucial role in validating the authenticity of IP address announcements. Within this framework, network operators employ ROAs to specify which AS is authorized to announce particular IP address prefixes. Any deviation from these established routes can be swiftly flagged or outright rejected, thereby reducing the likelihood of BGP hijacking. Building on the foundation laid by RPKI, Route Origin Validation (ROV) was introduced as an enforcement mechanism. While RPKI outlines the guidelines, ROV ensures adherence by validating the authenticity of the AS announcing a prefix.

This validation is carried out using ROAs, which detail the prefixes an AS is allowed to announce and identify which autonomous system number can initiate particular prefixes. To accomplish this, third-party software (known as a validator) establishes an RPKI-to-Router session with routers, verifying the information obtained from trust anchors. Post successful validation, the ROA can be utilized to create route filters, preventing potential hijacks or misconfigurations.

However, these security measures hinge on the cryptographic assurances furnished by the Public Key Infrastructure (PKI), and therefore, on its robustness and integrity. The PKI, a linchpin of digital trust, operates on a hierarchical system where the role of certificate authorities (CAs) is pivotal. This hierarchy, while effective, harbors vulnerabilities, especially when higher-level entities like parent CAs are compromised, potentially triggering a cascade of security breaches.

RPKI Trust Chain

Trust within the RPKI initiates at the Internet Assigned Numbers Authority (IANA), which delegates IP prefix management to the five Regional Internet Registries (RIRs). These entities, in turn, issue certificates delegating prefix ranges to Local Internet Registries (LIRs) or end-users. These entities can then generate ROAs, fortifying the hierarchy of trust. This chain of trust and authorization is depicted in Figure 2, showcasing how RIRs enable LIRs to authenticate ROAs for specific address blocks, with further delegation capabilities extended to end-users.

Fig2. Trust Chain

Analysis of Trust Chain Security in RPKI

Now, we present an overview of the possible adverse actions and associated risks concerning the security of the Trust Chain in RPKI.

At the crux of RPKI's vulnerabilities lies its reliance on a hierarchical trust model. With top-level entities vested with the authority to issue, invalidate, or supersede resource allocations, the system's strength (or weakness) hinges on its highest trust nodes. Thus, the RPKI system is susceptible to a range of adverse actions. The security of the entire infrastructure could be jeopardized if key nodes, especially those at higher levels in the hierarchy, are targeted.

The list of adverse actions against the RPKI includes but is not limited to: Deletion, Suppression, Corruption, Injection, Modification, and Revocation of existing records. These actions are concerning, as they could redirect or halt substantial portions of web traffic. Unauthorized acquisition or compromise of higher-level keys in the hierarchy can lead to widespread data modification or the revocation of valid certificates. The centralized nature of trust in RPKI means that a disruption in the trust chain can have a ripple effect through the system.

RPKI, though a vital step forward in securing BGP routing, is not without its flaws. On one hand, the system's dependence on a hierarchical structure of trust means that the compromise of key entities can have disproportionately large impacts. On the other hand, only a fraction of the global routing table is currently covered by RPKI. While adoption is growing as more networks embrace this technology, a more secure underlying routing layer for the Internet is needed in the long run.

In the following section, we will explore some BGP hijacking attacks that exploited the aforementioned flaws, impacting the web3 industry.

BGP Hijacking and Web3: Case Studies

We now present an analysis of two notable attacks, the KLAYswap and the Celer Bridge, that employed BGP hijacking to steal funds from users. We will show how the attackers exploited the weak points of the routing infrastructures and why this was possible.

KLAYswap

On February 3rd, 2022, the crypto exchange KLAYswap fell victim to an attack, later identified as a BGP hijacking attack, which lasted approximately 2 hours. It ultimately resulted in losses of $1.9 million. This sophisticated cyber-attack leveraged multiple layers of vulnerabilities in the web's ecosystem.

__The Attack __

The focal point of the assault was a JavaScript library integral to the functioning of KLAYswap, named kakao.min.js, hosted on Kakao Corp's server. Figure 3 illustrates the legitimate and intended interaction between the user and KLAYswap.

Fig3. User-Klayswap Legitimate Interaction

Here, the user interacts with KLAYswap, which necessitates the user to access the kakao.min.js library hosted on Kakao's servers. Upon the user's request, Kakao's server provides access to the library, enabling the user to interact with KLAYswap using the kakao.min.js library. The user can then execute actions on the KLAYswap platform, which redirect to the original and legitimate smart contracts.

The attacker initiated the attack by deploying malicious contracts and setting up a malicious server hosting a counterfeit kakao.min.js library, containing altered addresses of the smart contracts KLAYswap was supposed to interact with. Following this, the attacker launched a preliminary BGP attack to execute a certificate forgery attack, thereby acquiring rights to announce the target pair [AS, IP- prefixes]. Having secured the certificate for the developers.kakao.com domain, the attacker updated the BGP record, announcing false pairs [AS, IP prefixes]. This action, constituting a secondary BGP attack, bypassed TLS verification, masking the illegitimacy of the attack, and rerouting the victim's traffic to the malicious network under the attacker's control.

Fig4. On-Going Attack: User-Klayswap Interaction

As depicted in Figure 4, when KLAYswap customers attempted to access the kakao.min.js library, they were served a malicious JavaScript file from the attacker's network instead of the legitimate file from Kakao's servers. This malicious script redirected users' cryptocurrency transactions to smart contracts and addresses controlled by the attacker.

Attack Phases

The KLAYswap case exemplifies a highly intricate attack, which can be delineated into several phases as outlined in this section.

1. Smart Contract and Malicious Server Deployment: In the preparatory phase, the attacker deployed several smart contracts and a server hosting malicious versions of kakao.min.js.

2. First BGP Attack: The attacker initiated the first BGP attack, preparing for a Certificate Forgery exploit against RPKI, crafting a fabricated yet valid Certificate to announce the target pair [AS, IP-Prefix], thereby bypassing cryptographic validations.

The website developers.kakao.com resolved to two IP addresses, 211.249.221.246 and 121.53.104.157, with Kakao Corp having sub-assignments of these addresses from Dreamline, a server hosting company.

The BGP table entry for IP address 211.249.221.246 was (7625, 211.249.216.0/21), and for IP address 121.53.104.157, it was (38099, 121.53.104.0/23). However, Dreamline had not configured proper RPKI ROA records for these routes. Cloudflare's RPKI services indicated the RPKI status for IP addresses 121.53.104.0/23 and 211.249.216.0/21 as "unknown," signifying no ROA for any routes originating from either of these ASN, as per rpki.cloudflare.com. This left these networks unprotected by RPKI.

Leveraging the missing RPKI record, the attacker commenced announcing BGP routes for (9457, 121.53.104.0/24) and (9457, 211.249.216.0/24), diverting all traffic toward the newly advertised route. By specification, BGP routers always favor the more specific (/24) route over the less specific (/23; /21), and lacking RPKI records, routers automatically accepted the more specific prefix announced by the attacker.

As illustrated by the Mutually Agreed Norms for Routing Security (MARNS), the correct setup of RPKI ROA records could have thwarted this hijacking. If Dreamline had properly set up RPKI ROAs as per the options in table1 and table2, routes originating from AS9457 would have been deemed invalid during the ROV, prompting many global operators to discard them.

Table 1. RPKI ROA Configuration Option1

With accurate configuration of these records, the hijack might have been entirely thwarted, or at the minimum, its damaging effects significantly contained.

__Certificate Forgery __

As detailed here, the crux of the KLAYswap incident revolved around neutralizing TLS, the bedrock encryption protocol supporting a substantial portion of secure web communications. The audacity of this onslaught lay not only in breaching the cryptographic safeguards but also in manipulating the trust chain inherent in the routing infrastructure.

While both KLAYswap and Kakao rigorously employed TLS, the assailants bypassed probing for vulnerabilities within TLS directly. Instead, they honed in on the Public Key Infrastructure (PKI), which TLS relies on to validate the identity of web servers.

Fig5. Legitimate Certificate Request

At the heart of this security theater are the Certificate Authorities (CAs), depicted in Figure 5. These entities, entrusted with the duty of issuing digitally signed certificates, were the primary targets. Ordinarily, CAs authenticate the identity of a requestor before dispensing a certificate, often leveraging domain control validation over HTTP to ascertain that the entity requesting a certificate genuinely controls the corresponding domain name. Especially when a server might be procuring a TLS certificate for the first time, this process typically unfolds over a less secure HTTP channel.

However, the attacker identified a flaw, as illustrated in Figure 6. They executed a BGP hijack, rerouting domain control validation traffic from the CA, impersonating the legitimate victim website (developers.kakao.com) and successfully duped the Certificate Authority. In this scenario, ZeroSSL, the CA, was tricked into issuing a signed certificate for the developers.kakao.com domain.

Fig6. Certificate Forgery Attack Under Ongoing BGP Attack

Final BGP Attack

Upon securing a valid RPKI certificate for the developer.kakao.com domain, the attacker commenced "legitimate" route announcements for that domain. At this juncture, as depicted in Figure 7, the attackers were poised to serve malicious JavaScript to unsuspecting KLAYswap users. The connection appeared to traverse a secure TLS, lending a deceptive veneer of credibility and protection, enabling the attacker to progress with the assault as portrayed in Figure 4.

Fig7. BGP Hijacking with illegitimate but valid certificate

Fund Obfuscation

In the terminal phase of the attack, the exploiter started to move funds across exchanges and DEXs. For a comprehensive reconstruction of fund movements, see the KlaySwap Post Mortem document.

Celer Bridge

On August 17, 2022, the crypto bridge Celer experienced a BGP hijacking attack. The attack persisted for approximately three hours and resulted in losses of roughly $235k. This incident bears a resemblance to the one executed against KLAYSwap, albeit with minor variances.

The main target of the attack was the Celer Network Bridge DApp frontend. Initially, the attacker deployed several malicious contracts on various blockchain networks, then launched a BGP attack to firstly obtain a valid TLS certificate, and subsequently to announce a new route aiming to redirect Celer Network Bridge DApp's users to another frontend under their control, as illustrated in Figure 8. The malicious frontend had altered smart contract pointers, redirecting instead to malicious smart contracts deployed by the attacker.

Fig. 8. Celer Bridge BGP Hijacking Effect

In this section we will explore the different phases of this complex attack.

Malicious Contract Deployment

On August 12, 2022, the attacker began deploying several malicious smart contracts on blockchain networks, including Ethereum, Binance Smart Chain (BSC), Polygon, among others. These contracts were the destinations to which users would be redirected after the completion of the BGP hijack.

BGP Hijacking and Certificate Forgery

At that time, the announcement of cbridge-prod2.celer.network at IP 44.235.216.69 was managed by Amazon with AS-16509 with a 44.224.0.0/11 route. On August 16, 2022, a day prior to the actual attack, the malicious actor initially crafted an entry in the AltDB Internet Routing Registry (IRR), a free alternative to the IRR databases overseen by RADB and the five RIRs. IRRs are public repositories where ASes declare their routing policies, including their commercial relationships with other network providers. IRRs further serve Internet Service Providers (ISPs) in constructing their route filters based on the information housed in IRR databases. Within this step, the attacker ensured his announcement wouldn't get filtered; by modifying the data contained in AltDB, the attacker successfully deceived a transit provider into believing that a UK-based hosting facility had permission to route address space owned by Amazon Web Services, where the Celer Bridge infrastructure resided.

Subsequently, the attacker commenced announcing a bogus AS path of his hijack, inclusive of an Amazon ASN as the origin, effectively bypassing the RPKI ROV protection. Similar to the KLAYswap incident, demonstrating control over the subdomain to certificate authority GoGetSSL, he successfully forged a new TLS certificate for cbridge-prod2.celer.network. Having acquired a valid TLS certificate, the attacker could announce the more specific route 44.235.216.0/24 AS-209243, bypassing security controls. Hence, the hijacker hosted his malicious smart contract, devised to redirect cryptocurrency funds to an account under his control, on the same domain, awaiting visits from individuals attempting to access the genuine Celer Bridge cbridge-prod2.celer.network page, announcing a more specific route /24 that was favored by routers over a less specific route /11.

Fund Obfuscation

In the concluding phase of the attack, the exploiter initiated the movement of funds across various exchanges and swapping platforms. For a complete reconstruction of the funds movement, the reader is referred to Coinbase’s analysis of the attack.

Lessons Learned

The KLAYswap and Celer Bridge incidents serve as a compelling testament to the inherent vulnerabilities in our digital infrastructures. These attacks not only showcased the audacity of cybercriminals but also brought to light several weak points:

• Partial RPKI Adoption: The misconfiguration of RPKI ROA records.
• RPKI Trust Chain Vulnerabilities: Domain validation over insecure HTTP for initial TLS certificate issuance.
• Partial IRR Adoption: Highlighting the need for a global distributed IRR with built-in privacy prevention mechanisms.

The KLAYswap and Celer Bridge incidents present a compelling exposé on the precarious state of the internet's routing infrastructure, magnifying the criticality of comprehensive RPKI (Resource Public Key Infrastructure) adoption, and shedding light on the undervalued yet indispensable role of IRRs (Internet Routing Registries). This report also offers a stark reminder of the structural vulnerabilities that continue to pervade the digital landscape, despite advancements in cybersecurity.

The partial adoption of RPKI is indeed a critical concern. The absence of properly configured ROA (Route Origin Authorization) creates a fertile ground for malicious actors to exploit, enabling traffic hijacking and other nefarious activities. The current level of encouragement from major players falls significantly short of what is required to bring about a widespread change in the adoption trajectory. The urgency of this call is further amplified by the demonstrated ease with which adversaries can manipulate the RPKI trust chain, especially during the TLS certificate issuance phase, circumventing security barriers with alarming efficiency.

Lastly, IRRs are not widely adopted even though they are highly recommended by MARNS. IRRs theoretically provides a mechanism for validating the contents of BGP announcement messages and mapping an origin AS number to a list of networks. However due to the lack of a unified global registry and massive adoption, the quality of the information available can suffer from inconsistency across different IRRs and information staleness, which in turn can lead to potential incidents and misconfiguration as happened in the Celer Bridge cases.

Alarmingly, these attacks highlighted structural vulnerabilities that haven't been addressed. The breaches underscore evident deficiencies in our current web security measures. It points to the imperative need for sweeping security enhancements throughout the web landscape. The challenges thrown up by these incidents in terms of trust dynamics, in both the Internet's routing and certificate infrastructure, highlight the urgency of bolstering these domains against future threats.

Key Takeaways

Below, we provide a pragmatic roadmap for both project teams and users to bolster their security posture in navigating the digital ecosystem, particularly against the backdrop of BGP hijacking incidents.

For Teams

• Implement Security Measures: It is imperative for project teams to liaise with their network providers to ensure the implementation of all recommended security prevention measures like RPKI, ROA, ROV, BGPSec, and IRRs. These mechanisms have been endorsed by internet infrastructure maintainers and can serve as a robust first line of defense against the types of exploits discussed earlier.

• Deployment on IPFS: The deployment of frontends and dependencies on the InterPlanetary File System (IPFS) is a viable tactic, one which we recently examined. Unlike traditional location-based methods, IPFS's content-based hashing ensures that users access the authentic content they seek, thereby negating the risks associated with BGP hijacks. Furthermore, this decentralized approach reduces reliance on third-party services, which is a significant stride towards mitigating associated risks.

• Continuous Monitoring: The importance of continuous monitoring cannot be overstated. Employing monitoring tools that can swiftly alert the team to unauthorized changes or suspicious activities on their hosting setup is crucial. This proactive measure can significantly reduce the reaction time, thereby minimizing potential damage.

For Users

• Contract Address Verification: It's smart for users to verify the legitimacy of the smart contract they intend to interact with.

• Limiting Third-Party Approvals: Even reputable projects are susceptible to hacks. Hence, it's prudent for users to avoid granting infinite approval over their funds to third parties. Restricting the scope and duration of approvals can help mitigate potential losses in the event of a security breach.

• Staying Informed: Staying abreast of official communications from the project teams is crucial. Regular visits to official channels can provide timely updates on any recognized security issues or ongoing attacks, empowering users to make informed decisions, especially when it comes to inserting sensitive information.

These takeaways underscore a balanced approach, where both project teams and users play active roles in fostering a secure digital environment.

Ongoing Research Efforts on Security Mechanisms

In this section we provide an overview of the ongoing research efforts on the security mechanisms that should help secure the global Internet routing infrastructure. Interestingly, most of the ongoing efforts are exploring the application of DLTs systems.

BGP Blockchain

The inefficacy of existing security solutions like RPKI, ROAs, ROV, and BGPSec in preventing BGP routing disruption has propelled the need for innovative measures. The hierarchical structure of RPKI, marked by potential single points of failure, necessitates a paradigm shift towards decentralized security models. The scientific community has already come up with several proposals about how the application of DLTs could be beneficial in securing the RPKI trust chain. A notable endeavor in this direction is the exploration by the Internet Engineering Task Force (IETF) of a BGP Blockchain, aiming to leverage Distributed Consensus Systems (DCS) such as blockchain for securing the global routing infrastructure.

The envisaged benefits of a DLT-based system in this context include:

• Fraudulent BGP Origin Announcements Prevention: Mitigating the risks of illegitimate BGP announcements which could lead to traffic diversion or blackholing.
• BGP Update Validation: Ensuring that incoming BGP updates are legitimate and conform to established routing policies.
• Routing Policy Provision: Enabling a mechanism to enforce Quality of Service (QoS) policies.
• BGP Configuration File Protection: Shielding crucial configuration files from unauthorized access or modifications.
• Path Validation: Verifying the authenticity and integrity of the paths through which data traverses.
• BGP Controller Security: Ensuring the security of controllers managing BGP operations.
• Blockchain Security against BGP Vulnerabilities: Protecting the very blockchain that underpins these solutions from potential compromises through BGP vulnerabilities.

However, the proposed DLT solutions come with inherent challenges including:

• DCS Convergence Latency: The time taken for the network to reach a consensus could potentially affect real-time routing decisions.
• Communication Costs: The overhead associated with maintaining and synchronizing a distributed ledger.
• Inconsistency Management: Handling inconsistent states that may arise due to network partitions or other factors.

For details on the open discussion and drafts we refer the reader to the following documents: Draft00, Draft01, and Draft02.

DLT-Based IRRs

The discussion extends to employing DLT for IRRs, which are critical repositories for ASes to declare their routing policies. Current IRR systems suffer from lack of global adoption and consistency. Proposals like Blockchain Internet Routing Registry (BIRR) or Internet Routing Blockchain (IRB) envision a unified, DLT-based IRR system that could offer a solution to these issues.

Previous research on the topic includes different proposals to implement IRRs using DLTs technologies, such as the Blockchain Internet Routing Registry (BIRR) or Internet Routing Blockchain (IRB). The proposed solutions, apart from providing a concrete solution to unify the set of distributed and individually operated repositories, convey the possibility to come up with a solution with built-in privacy features. Interestingly, such a solution would further facilitate the mass adoption of IRRs. Indeed it is a fact that ISPs are less prone to reveal their commercial relationship and thus to include their routing policy into IRRs as widely recommended. However, thinking about IRRs as a DLTs based solution could potentially overcome this issue. Indeed, different privacy mechanisms could be introduced, with the set of information only readable by certain members of the system. Deeper privacy could be even reached using a DLT based solution including Zero Knowledge capabilities. Within such a system, routing policies could be used and validated without being actually revealed.

IPFS as a Potential (Yet Partial) Countermeasure Against BGP Hijacking

In our previous piece, we introduced IPFS and illustrated how this system could potentially thwart DNS hijacking attacks. Now, we aim to highlight the potential merits and limitations of IPFS as a countermeasure against BGP Hijacking.

Unlike BGP, which is a protocol designated for path determination during internet data transfers, IPFS proposes a decentralized methodology for storing and sharing hypermedia through a distributed file system. Bypassing the conventional location-based addressing, IPFS employs content-based addressing; users request data by its content hash, enabling content retrieval as long as any node within the system retains it.

How might IPFS mitigate the ramifications of BGP hijacking?

• Content Addressing: The content-based addressing of IPFS implies that BGP hijacking, which reroutes traffic based on IP address assertions, cannot undermine the integrity of content on IPFS. Since content is retrieved based on its hash, its authenticity remains preserved regardless of the route traversed to reach the user. For instance, had KLAYswap utilized kakao.min.js deployed over IPFS, the aforementioned attack could have been averted. Similarly, if the Celer Bridge frontend was deployed over IPFS, the requested hash wouldn’t have matched during the BGP Hijacking, thereby precluding such an incident.
• Decentralized Architecture: The inherent decentralization of IPFS fortifies it against various network threats. Even if a part of the network succumbs to BGP hijacking, other unaffected nodes can continue dispensing content unabated.

However, it's crucial to understand IPFS's limitations. While it can safeguard data integrity in a BGP hijacking event, it doesn't deter the hijacking attempt itself. Attackers can still intercept or disrupt traffic, posing threats to data availability or engaging in other malevolent acts.

In essence, IPFS introduces a resilient layer against data tampering stemming from BGP hijacking, yet addressing the intrinsic vulnerabilities of BGP is imperative for a comprehensive solution against such threats.

Conclusions

The digital ecosystem is at a pivotal juncture where the vulnerabilities in our entrenched systems are increasingly being laid bare. The incidents involving KLAYswap and Celer Bridge accentuate the holes in our current digital security paradigm.

At the crux of these incidents lie the issues of partial RPKI adoption, RPKI trust chain vulnerabilities, and the absence of a globally unified IRR system, underscoring the intricacy of the challenge before us. These are not merely operational issues; they epitomize a foundational problem in the structuring of our digital systems. The need for a more robust and widespread adoption of RPKI is clear. Yet, as observed, this alone may not remedy all vulnerabilities. The inherent vulnerabilities in the RPKI trust chain and the problems surrounding IRR adoption show that our stance towards digital security necessitates a significant reassessment. Internet actors, both major and minor, must rise to the occasion, recognizing that the prevailing methodologies are lagging behind in the war against evolving cyber threats.

The proposed security measures, for both teams and users, are progressive steps. However, it's evident that a multi-faceted strategy is needed. This encompasses not only the adoption of best practices but also innovation in the domain of digital trust.

The exploration into Distributed Ledger Technologies (DLTs) as potential solutions exemplifies the digital community's adaptability and quest for enhanced security mechanisms. Whether it's the notion of BGP Blockchain or decentralized Internet Routing Registries, the focus is on redefining trust, decentralizing control, and instilling resilience into the system.

Yet, as with all innovations, challenges arise. The potential latency, communication costs, and inconsistency issues are non-negligible. The overarching question is: Will BGP Blockchain emerge as “the killer application” of DLTs technology? While the verdict is pending, it's clear that the pathway towards a more secure digital future is multi-dimensional. The potential of technologies like IPFS exudes a glimmer of hope, yet it also serves as a reminder that while solutions to specific problems may be found, the pursuit for a holistic, impervious digital security framework continues.

The incidents we've studied underscore the urgency of this endeavor. As we advance, we must prioritize collaboration, innovation, and a proactive approach towards security. It transcends merely averting financial or data losses; it's about safeguarding the very fabric of trust that is the foundation of our digital lives.