The CURE to Vulnerabilities in RPKI Validation

The CURE to Vulnerabilities in RPKI Validation

Speakers: Donika Mirdita

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=MqLhL28d7oA

Overview

The Border Gateway Protocol (BGP), the foundational routing protocol of the Internet, faces a critical and persistent vulnerability: route hijacks. Due to BGP's inherent trust model, any router can announce reachability for any IP prefix, even those it doesn't legitimately own. This susceptibility leads to severe consequences such as traffic misdirection, blackholing, and widespread service disruption. To counter this, the Internet Engineering Task Force (IETF) standardized the Resource Public Key Infrastructure (RPKI). RPKI enables Autonomous Systems (ASes) to cryptographically assert their ownership of IP prefixes by issuing digitally signed Route Origin Authorizations (ROAs). These ROAs bind specific AS numbers to IP prefixes, allowing Route Origin Validation (ROV) to be performed by border routers, which then drop unauthorized BGP announcements, thereby mitigating hijacks.

The integrity and availability of RPKI validation data are paramount, as they directly impact the security of Internet routing. Relying Party (RP) implementations are the critical software components responsible for retrieving, processing, and validating RPKI objects from distributed repositories. They compile a list of valid ASN-IP pairs into a Validated ROA Payloads (VRPs) file, which BGP routers then consume. The talk highlights that if an RP malfunctions or ceases to provide data, the validation data expires, leaving routers exposed to hijacks. As of June 2023, a significant 37.8% of major networks have adopted RPKI, underscoring the urgent need for a thorough analysis of RP software correctness, stability, and consistency.

Despite RPKI's growing importance, a systematic and comprehensive analysis of RP implementations for resilience against errors, attacks, and compliance with standards has been largely absent. Developers typically rely on manual testing and unit tests, which are insufficient given the complexity and statefulness of RPKI. The speaker, Donika Mirdita, introduces CURE (Comprehensively Usable RP Evaluator), a novel, language-agnostic, black-box fuzzing framework designed to systematically test RPKI validation software. This research addresses the formidable challenges of fuzzing RPKI, including its cryptographic signatures, complex object interdependencies, statefulness, and the lack of flexible testing environments.

Background

▶ Watch: BGP vulnerabilities and RPKI's solution for routing security (0:00)

The RPKI validation process is a complex, hierarchical system designed to establish a chain of trust for Internet routing resources. RPKI information is stored in distributed repositories hosted on Publication Points (PPs). These repositories contain various cryptographically signed objects, including ROAs, Certificates (CAs), Certificate Revocation Lists (CRLs), Manifests (MFTs), and other emerging objects like AS Provider Authorizations (ASPAs) and Global BGP Routers (GBRs). All these objects are signed by the private key of the CA managing the associated resources.

Border routers do not interact directly with these repositories. Instead, RPs perform the heavy lifting. Each system utilizing RPKI installs its own RP, which continuously fetches and validates objects from all RPKI repositories. This process begins by establishing a chain of trust from five globally trusted Trust Anchor Locators (TALs), which are pre-configured in every RP installation and point to the root CA certificates of the five global Regional Internet Registries (RIRs). The RP workflow involves several key functions:

1. Recursive Data Fetching: RPs discover PPs via URIs embedded in CA certificates and fetch data. They primarily use the RPKI Repository Delta Protocol (RRDP), an HTTPS-based protocol for efficient incremental updates using notification.xml, snapshot.xml, and delta.xml files. The legacy rsync protocol serves as a fallback.
2. Object Validation: RPs follow a strict processing order. CA certificates are validated first, then the RP traverses the CA tree, using Subject Information Access (SIA) extensions to find and validate child certificates. Once a CA certificate is validated, its public key is used to validate other RPKI objects within that repository. CRLs are validated by checking their signature with the CA's public key and ensuring RFC 5280 compliance. ROAs and other RPKI objects involve two signatures: the object's payload signed by a one-off End-Entity (EE) certificate, and the EE certificate itself signed by the CA.
3. Integrity Validation: Manifest files, which list all objects in a repository along with their hashes, are crucial for verifying the integrity of the repository's contents.
4. VRPs Compilation: After all objects are processed and cached locally, the RP compiles all discovered valid ROAs into the VRPs file, which is then consumed by BGP routers for route origin validation. The continuous availability of this data stream is vital; any interruption can lead to data expiration and renewed vulnerability to BGP hijacks.

Despite the critical role of RPKI, fuzzing its implementations presents unique and formidable challenges that traditional fuzzing techniques struggle to address. The talk meticulously outlines these hurdles:

1. Cryptographic Signatures: RPKI objects are cryptographically signed. Generating random yet validly signed inputs is exceptionally difficult, as signatures depend on object content and must be re-generated for every fuzzer-created object.
2. Complex Object Structure and Dependencies: RPKI objects have intricate structures and interdependencies (e.g., a ROA needs an EE certificate, signed by a CA certificate, which depends on a TAL). Crafting meaningful RPKI objects that satisfy these complex dependencies automatically is a significant hurdle.
3. Statefulness: RPKI is a stateful system; RPs cache validated objects across multiple validation runs. Testing such stateful systems effectively is computationally intensive.
4. Custom Publication Point Emulator: Effective RP testing requires a highly flexible PP that can dynamically create valid repositories around arbitrary test objects and adapt fields. Existing PP software, such as Krill, is designed for publishing high-quality, valid objects, not for stress-testing RPs with potentially malicious inputs.
5. Complexity of Function Decoupling: RP software often exhibits tight coupling between its components, making it difficult to isolate specific functions for targeted fuzzing. Building a universal testing harness across diverse RP implementations is a labor-intensive task.
6. Manual Code Adaptation: Many critical RP components are not exposed externally, necessitating source code modification or extraction of functions for testing, which is not scalable given the continuous evolution of RP software.
7. Eliminating False Positives: Traditional fuzzers might detect crashes in isolated functions that do not manifest as actual vulnerabilities in a full RP deployment. A robust approach must emulate normal RP operation to ensure that identified crashes represent true security flaws.

These challenges highlight the necessity for a novel, sophisticated approach to RPKI fuzzing that can effectively manage cryptographic requirements, complex dependencies, and statefulness while remaining language-agnostic and efficient.

Key Findings

▶ Watch: Overview of the RPKI data validation process (2:00)

The comprehensive fuzzing campaign conducted with CURE, totaling 72 hours and approximately 648 million test cases across various object types, yielded significant and alarming discoveries. The research uncovered 18 previously unknown critical vulnerabilities, including Denial of Service (DoS) and VRP cache poisoning attacks, alongside 7 instances of RFC inconsistencies. Five CVEs have already been assigned: CVE-2023-39914, CVE-2023-39915, CVE-2023-39916, CVE-2022-3029, and CVE-2022-3616.

The findings can be broadly categorized:

1. Path Traversal: RPKI Poisoning: A critical path traversal vulnerability was identified in Routinator's object storage module, specifically when the RRDP-keep-responses option is enabled. This flaw, present in Routinator versions prior to 0.12.0, allows an attacker controlling a malicious PP to deliver a payload, such as a fake.TAL file, into the Routinator installation's TAL folder. During the subsequent validation run, Routinator loads this malicious TAL, trusts its certificates, and proceeds to validate arbitrary malicious ROAs. This mechanism allows an attacker to inject fake prefix-AS pairs into Routinator's VRP cache, effectively circumventing RPKI protection without detection. While TAL management has been updated to mitigate the poisoning aspect, the underlying path traversal vulnerability remains, posing a risk for arbitrary malware delivery. The research showed that 79.4% of Routinator instances were vulnerable to the full poisoning attack, with the remaining 20.6% still exposed to path traversal.

1. Crashes: RPKI Downgrade Attacks: Numerous DoS vulnerabilities were discovered across Routinator, Fort, and OctoRPKI. These vulnerabilities, triggered by malformed RPKI objects, lead to a total application crash. An attacker with control over a valid Publication Point could potentially crash all vulnerable RP instances from a single attack vector.

• Routinator: 11 bugs were found, primarily stemming from external libraries like rpki-rs and bcder. These included assertion failures, lack of sanity/length checks, and poor error handling for issues such as truncated manifest content (MFT#1), erroneous ROA content length (ROA#2), prefix lengths exceeding 128 bits (ROA#3), and invalid tag data (MFT#4).
• OctoRPKI: Written in Go with its own parsing and validation libraries, OctoRPKI exhibited 5 bugs. These included index out-of-range panics during manifest decoding (MFT#1, MFT#2, MFT#3) and nil-pointer expressions caused by faulty Authority Key Identifiers in CRLs (CRL#4).
• Fort: A DoS vulnerability was identified in its RTR server. Sending a message larger than the expected Protocol Data Unit (PDU) slot caused memory corruption and a full application crash.

The impact of these crashes is severe: RPs lose their live session with BGP border routers, causing routers to flush their RPKI cache and temporarily disable RPKI validation. Default flushing periods range from 360 seconds (Cisco) to 7200 seconds (FRR). If RPs are not manually restarted, routers cease applying RPKI validation, effectively downgrading the entire RPKI protection. All Routinator, OctoRPKI, and Fort deployments were found vulnerable to these DoS attacks.

1. Cache Disparity: Silent Discarding of Valid Objects: Beyond outright crashes, CURE identified instances where RPs silently discarded validly signed RPKI objects. This occurred when RPs were fed large objects, causing snapshot parsing to fail for individual PP repositories. The RP would not crash but would silently discard objects from the affected PP, leading to an effective downgrade of RPKI protection. The file size thresholds for triggering this varied significantly across RPs and object types: for manifest files, rpki-client failed at 4MB, Fort at 7MB, Routinator at 20MB, and OctoRPKI at 1.9GB. With the projected growth of RPKI repositories due to IPv6 adoption and new record types, manifest sizes are expected to grow 3-4x, making this issue more prevalent even under benign conditions.

1. RFC Inconsistencies: The analysis revealed widespread non-conformance to RFC standards, with RPs either ignoring strictly defined checks or handling undefined corner cases inconsistently. This leads to validation discrepancies and security issues:

• Manifest/CRL Validity (RFC 9286): OctoRPKI accepted manifests with expired CRLs, despite RFC 9286 suggesting manifest nextUpdate should match CRL nextUpdate. No RPs checked for misalignment of EE certificate validity intervals.
• CRL Format (RFC 6487): OctoRPKI and rpki-client ignored missing mandatory extensions (Authority Key Identifier, CRL Number). OctoRPKI also accepted CRLs with false or missing signature fields. Routinator, conversely, had a strict, non-RFC-defined format rule for CRL numbers, causing it to discard entire CRLs accepted by other RPs.
• ROA ipAddrBlocks (RFC 6482): The RFC is vague on the organization of ipAddrBlocks. Routinator was overly strict, allowing only one entry per IP family, while other RPs accepted multiple entries. This could lead to ROA loss if PPs did not conform to Routinator's restrictive interpretation.
• ROA MaxLength (RFC 6482): If MaxLength was not a parseable integer, all RPs except OctoRPKI dropped the ROA, causing unequal ROA distribution.
• Certificate Serial Numbers/Extensions (RFC 6487): Fort and rpki-client enforced unique serial numbers and critical key_usage/certificate_resources extensions, whereas Routinator and OctoRPKI accepted identical certificates and ignored critical extension requirements.
• Snapshot session_id (RFC 8182): OctoRPKI failed to check for session_id consistency between notification.xml and snapshot.xml, rendering it vulnerable to replay attacks.

These idiosyncratic behaviors result in the silent discarding of valid ROAs, leading to a downgrade of RPKI protection for affected regions, even for legitimately issued ROAs.

The collective impact of these vulnerabilities is substantial. The research found that 87.6% of ASes are vulnerable to RPKI downgrade, with 45.7% susceptible to both poisoning and DoS attacks, and 41.9% to DoS attacks only. This means RPKI protection for at least 354,869 prefixes can be disabled. Furthermore, analysis of real-world RPKI data showed significant VRP discrepancies between RPs: Routinator (441,770 VRP entries), Fort (435,002), OctoRPKI (434,074), and rpki-client (441,777) as of June 27th, 2023. These differences are not due to network errors but processing inconsistencies. For instance, OctoRPKI discards 1744 prefixes by dropping those with lengths greater than /24 for IPv4 or /48 for IPv6. Fort discards 6405 IP prefixes by dropping ROAs with the OrganisationName issuer attribute in EE-certificates, impacting large cloud providers like Amazon (AS14618 & AS16509) and Microsoft (AS8075). Resource owners are often unaware that their legitimately issued ROAs may be silently dropped by certain RPs, leaving their prefixes unprotected.

Technical Deep Dive

▶ Watch: RRDP and rsync protocols for RPKI repository updates (3:10)

To overcome the inherent difficulties in fuzzing RPKI, the researchers developed CURE (Comprehensively Usable RP Evaluator). CURE is a novel, first-of-its-kind, language-agnostic, black-box continuous testing middleware designed to emulate a highly flexible RPKI publication point. Its core innovation lies in its ability to "repository-fy" any arbitrary RPKI object. Instead of requiring a rigid, pre-defined repository structure, CURE dynamically builds a scaffold repository around a given test object, adapting to its specific type and dependencies. This dynamic scaffolding is crucial for effective fuzzing, allowing CURE to test a vast array of scenarios.

CURE's object generation strategy accommodates all RPKI object schemas and types, including ASN.1, XML, and vCard, as detailed in Table II of the presentation. It employs two main approaches:

1. Random Byte Mutation: This technique applies arbitrary bit flips, cuts, deletions, or insertions to a base corpus of RPKI objects. Its primary goal is to target parsing and schematic errors, generating malformed inputs that stress-test the initial processing routines of RPs.
2. Structure-Aware Generation: To delve deeper into the internal validation logic, CURE uses structure-aware mutations. This approach generates schema-abiding and correctly encoded test cases with specific, targeted random mutations within their fields. This ensures that parsing checks are passed, allowing the fuzzer to test the validation pipeline for more subtle security issues and cache inconsistencies.

CURE is highly efficient, capable of generating millions of objects within a 24-hour period. It interfaces with the corpus generation module, processes the newly generated objects, and inserts them into an RPKI repository. This repository is then exposed to the RPs via either the RRDP or rsync protocol. The RP interaction module manages the execution of the target RPs, detects crashes, and reports anomalies. The framework was extensively tested against the four major RP implementations currently in use: Routinator, FORT, OctoRPKI, and rpki-client. The RIPE NCC Validator was excluded as its support had been discontinued.

The implementation details of CURE reveal its sophisticated design:

• Object Generation Interface: CURE supports two modes. Batch-mode is optimized for continuous fuzzing, consuming objects from a designated folder and feeding them to RPs in configurable batches, allowing for indefinite testing. Standalone-mode is for targeted analysis, taking a single RPKI object, building a repository around it, executing RP validation, and generating a detailed error analytics report.
• Building a Repository: Due to the complex, interdependent nature of RPKI objects, CURE cannot simply insert objects into a static template. It dynamically adapts fields and values within the object and generates necessary auxiliary objects. For instance, a single ROA requires the generation of 8 auxiliary RPKI objects, 5 signatures, and 3 hashes, with multiple fields needing dynamic adaptation. For ROAs, ASPAs, and GBRs, CURE appends an EE-certificate signed by a CURE child CA, with the EE-certificate's digest and signature dynamically generated for each test case. For certificates and CRLs, dynamic fields like signature, parent key identifier, and issuer name must be adapted to reflect the repository content.
• Replacement Strategies: CURE offers flexible strategies for field adaptation: Optimistic replacement (replaces all fields needing adaptation), Targeted replacement (replaces only fields flagged by the generation algorithm for structure-aware fuzzing), Parseable replacement (changes only well-formatted fields for randomly mutated objects), and No replacement (leaves fields intact, risking parsing failures). After adaptation and signing, the object is inserted into a complete RPKI repository, including ROAs, Manifests, and CRLs, to enable inconsistency detection. Auxiliary objects are cached to reduce computational overhead.
• Interacting with RPs: CURE executes RPs in a single-validation mode, meaning they run and terminate after one validation round, allowing precise control over execution time. Crash detection relies on two indicators: a non-zero exit code from the RP process, or the absence of a generated VRP file. Upon detecting a crash, CURE pinpoints the exact object responsible and generates a detailed crash report. For inconsistency detection, if all RPs produce VRP files, CURE parses them and reports any discrepancies in the accepted ROAs.

Performance Optimization was a critical aspect of CURE's development to ensure high testing throughput. The initial baseline using Krill, a popular RPKI publication point, showed bulk creation of 1000 ROAs taking 122.7 seconds (122.7ms per ROA), resulting in only 8.1 ROAs per second – insufficient for fuzzing. CURE implemented several optimizations:

1. Removed Unnecessary Operations: By removing Krill's stringent checks, which ensure only valid ROAs are added, CURE reduced the time for 1000 ROAs to 77.0 seconds (77ms per ROA), achieving 12.98 ROAs per second.
2. Keys Generation Caching: RSA key generation for ROAs accounted for 85% of the execution time. For fuzzing, unique keys can be pre-calculated and cached. With cached keys, 1000 ROAs took 2.25 seconds (2.25ms per ROA), boosting throughput to 400 objects per second. Signature generation, being content-dependent, could not be cached.
3. Parallel Processing: Object creation and signing are atomic tasks, allowing for parallelization. CURE, when executed with 5 signing processes, achieved processing times of less than 1ms per object, exceeding 1000 objects per second.
4. Hardware Optimization: Leveraging multiprocessing on a server with two XEON Platinum 8380 processors (40 physical cores), CURE reached an astonishing speed of 13,000 objects per second. This optimized speed significantly surpasses the validation speed of the RPs themselves (e.g., Routinator, the fastest RP, processes 4545 ROAs per second), ensuring that RPs are never idle and maximizing testing efficiency.

A notable limitation of CURE is its black-box design, meaning it is not coverage-guided. This was a deliberate trade-off to achieve language-agnosticism and high execution speed with minimal setup, contrasting with labor-intensive, language-specific grey-box fuzzers.

Demo / Proof of Concept

▶ Watch: Why fuzzing RPKI validation software is exceptionally challenging (4:00)

While the talk did not feature a live demonstration of CURE or an exploit, it provided detailed conceptual proof-of-concept explanations for the identified vulnerabilities, illustrating how an attacker could leverage them. The mechanisms for the most critical attacks were clearly articulated:

1. RPKI Poisoning via Path Traversal: The presentation conceptually demonstrated how an attacker could exploit the path traversal vulnerability in Routinator. By setting up a malicious Publication Point (PP) and crafting a URI containing malicious characters (e.g., ../../../), the attacker could deliver a fake.TAL file. This fake.TAL would then be written to the Routinator installation's trusted TAL folder, effectively pointing Routinator to non-RIR certified PPs. In subsequent validation runs, Routinator would load this malicious TAL, implicitly trust its associated certificate, and then validate arbitrary malicious ROAs supplied by the attacker's PP. This allowed the attacker to inject fake prefix-AS pairs into Routinator's VRP cache, effectively bypassing RPKI security.

1. Denial of Service (DoS) Attacks: The talk described how malformed RPKI objects could be used as proof-of-concept triggers for DoS vulnerabilities. For example, feeding Routinator an ROA with an erroneous content length (ROA#2) or a prefix length exceeding 128 bits (ROA#3) would cause the application to crash. Similarly, an OctoRPKI instance could be crashed by a manifest with an out-of-range index during decoding (MFT#1), and Fort's RTR server could be brought down by sending a message larger than its expected Protocol Data Unit (PDU) slot. These conceptual PoCs highlight that a single malicious object, delivered through a compromised or attacker-controlled PP, could lead to a full RP crash, causing border routers to flush their RPKI caches and temporarily disable RPKI validation.

1. Silent Discarding due to Cache Disparity: The research conceptually showed how validly signed, but excessively large, RPKI objects (e.g., a manifest file exceeding 4MB for rpki-client or 20MB for Routinator) could cause snapshot parsing to fail. While not a crash, the RP would silently discard objects from the malfunctioning PP. This effectively demonstrates how an attacker could inflate object counts or sizes to cause certain legitimate ROAs to be ignored by RPs, thereby silently downgrading RPKI protection for affected prefixes.

These conceptual proofs of concept, backed by CURE's extensive testing, confirm the feasibility and impact of these vulnerabilities on real-world RPKI deployments.

Defensive Implications

▶ Watch: Key technical hurdles: signatures, statefulness, custom PPs (4:15)

The findings from the CURE research underscore the critical need for immediate and sustained action from network operators, RPKI software developers, and the broader Internet community to enhance the security and resilience of RPKI validation.

1. Prompt Software Updates and Patching: Network operators must prioritize updating their RPKI Relying Party (RP) software to the latest versions. The identified vulnerabilities, particularly the path traversal in Routinator (affecting versions before 0.12.0) and the DoS bugs in Routinator, OctoRPKI, and Fort, necessitate immediate patching. Regularly monitoring security advisories and release notes from RP vendors is crucial.
2. Robust Monitoring and Alerting: Implement comprehensive monitoring for RP health and output. This includes tracking the operational status of RP processes, the consistent generation and content of VRP files, and any unexpected changes or cessations in data streams. Alerts should be configured for RP crashes, failures to produce VRPs, or significant discrepancies in VRP counts, enabling rapid response to potential attacks or malfunctions.
3. Deployment Diversity and Redundancy: Where feasible, consider deploying multiple, diverse RP implementations. Relying on a single RP software introduces a single point of failure. Running different RPs (e.g., Routinator and rpki-client) can provide resilience against vulnerabilities specific to one implementation and allow for cross-validation of VRP outputs, helping detect silent discarding or inconsistencies.
4. Stricter RFC Interpretation and Canonical Behavior: The research highlights that vague RFC specifications contribute significantly to inconsistencies. The RPKI community, including IETF working groups and RIRs, should work towards developing more rigorous and unambiguous requirements for the canonical behavior of RPKI validation. This includes defining clear error handling for corner cases and mandating specific checks currently ignored by some RPs (e.g., session_id consistency, mandatory certificate extensions).
5. Enhanced Resource Owner Awareness: Resource owners issuing ROAs must be made aware of the current inconsistencies in RP processing. They should understand that a ROA deemed valid by one RP might be silently discarded by another due to differing RFC interpretations or processing thresholds. Tools or services that can validate ROA acceptance across major RP implementations could help resource owners ensure their prefixes are adequately protected across the Internet.
6. Continuous Testing and Fuzzing: RP developers should integrate advanced fuzzing techniques, like those provided by CURE, into their continuous integration/continuous deployment (CI/CD) pipelines. CURE, now publicly available, offers a powerful means to systematically uncover vulnerabilities and ensure RFC compliance, leading to more robust software.
7. Consideration of Infrastructure Limits: Network operators and RPKI providers (like RIRs) must anticipate the growth of RPKI repositories, especially with IPv6 adoption. The discovered cache disparity issues related to large object sizes indicate that current RP implementations might struggle with future repository scales, leading to silent discarding of valid objects. Infrastructure planning should account for these processing limitations.

By addressing these defensive implications, the Internet community can collectively improve the security posture of RPKI, moving towards a more robust and trustworthy global routing infrastructure.

Key Takeaways

• RPKI Implementations are Immature and Vulnerable: Despite its critical role in securing BGP, current RPKI Relying Party (RP) software implementations exhibit significant immaturity, leading to numerous critical vulnerabilities and inconsistencies.
• CURE is a Novel and Effective Fuzzing Tool: The research introduced CURE, the first automated, language-agnostic, black-box fuzzing system specifically designed for RPKI. Its innovative "repository-fying" approach and performance optimizations enabled testing at an unprecedented scale (13,000 objects/second).
• Critical Vulnerabilities Discovered in All Major RPs: CURE identified 18 previously unknown critical vulnerabilities, including RPKI poisoning via path traversal (affecting 79.4% of Routinator instances), and Denial of Service (DoS) attacks (affecting all Routinator, OctoRPKI, and Fort deployments), leading to 5 assigned CVEs.
• Widespread RPKI Downgrade Risk: The discovered vulnerabilities can lead to a silent downgrade or complete disabling of RPKI protection. Overall, 87.6% of ASes are vulnerable to RPKI downgrade, leaving protection for at least 354,869 prefixes at risk.
• RFC Inconsistencies and VRP Discrepancies Abound: All RPs show non-conformance to RFCs and significant discrepancies in VRP generation. This leads to valid ROAs being silently discarded by some RPs (e.g., OctoRPKI discarding 1744 prefixes, Fort discarding 6405 prefixes from major providers), leaving resource owners unaware of their unprotected resources.
• Urgent Need for Canonical RPKI Validation Standards: The primary cause of these flaws is vague or non-existent RFC specifications for critical corner cases and non-critical field interpretations. There is an urgent need for the community to develop rigorous requirements for canonical RPKI validation behavior to ensure consistent and secure RPKI deployments.

About the Speaker(s)

Donika Mirdita is the speaker for "The CURE to Vulnerabilities in RPKI Validation" at the NDSS Symposium. Based on the transcript, she is a researcher focused on Internet routing security and the critical infrastructure surrounding protocols like BGP and RPKI. No specific affiliation or title was provided within the talk's metadata or transcript.