TVR Working Group Q. Wu Internet-Draft Y. Weng Intended status: Informational Z. Lai Expires: 3 September 2026 H. Li Tsinghua University 2 March 2026 Path Verification in LEO Satellite Networks draft-wu-tvr-path-verification-00 Abstract Emerging satellite Internet constellations such as SpaceX's Starlink deploy thousands of broadband satellites and construct LEO satellite networks (LSNs) in space, significantly expanding the boundaries of today's terrestrial Internet. However, due to the unique global LEO dynamics, satellite routers inevitably pass through uncontrolled areas, suffering from security threats. It is important for satellite network operators (SNOs) to enable verifiable risk- avoidance routing to identify path anomalies. This document specifies StarVeri, a network path verification framework tailored for emerging LSNs. StarVeri addresses the limitations of existing crypto-based and delay-based verification approaches and accomplishes efficient and accurate path verification through: (i) a segment-based verification protocol that divides paths into verifiable segments using dynamic satellite relays; and (ii) a hybrid verification approach combining cryptographic authentication with adaptive delay thresholds to verify each segment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 September 2026. Wu, et al. Expires 3 September 2026 [Page 1] Internet-Draft Path Verification in LSNs March 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Characteristics of LEO Satellite Networks . . . . . . . . . . 3 2.1. Preliminaries for LEO Satellite Networks . . . . . . . . 3 2.2. Potential Risks in Uncontrolled Areas . . . . . . . . . . 4 3. Impact of LEO Dynamics on Path Verification . . . . . . . . . 4 3.1. Today's Network Path Verification . . . . . . . . . . . . 4 3.1.1. Crypto-based path verification . . . . . . . . . . . 5 3.1.2. Delay-based path verification . . . . . . . . . . . . 5 3.2. A Case Study: LEO Dynamics Affect the Verification Accuracy . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Path Verification Framework for LEO Satellite Networks . . . 7 4.1. Framework Overview . . . . . . . . . . . . . . . . . . . 8 4.2. Verification Workflow . . . . . . . . . . . . . . . . . . 9 4.2.1. Packet header format . . . . . . . . . . . . . . . . 10 4.2.2. Relay verification procedure . . . . . . . . . . . . 11 4.2.3. Destination verification procedure . . . . . . . . . 12 4.3. Supporting Mechanisms . . . . . . . . . . . . . . . . . . 12 4.3.1. Relay configuration distribution . . . . . . . . . . 12 4.3.2. Session key negotiation . . . . . . . . . . . . . . . 13 4.3.3. Intra-segment probing . . . . . . . . . . . . . . . . 13 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Wu, et al. Expires 3 September 2026 [Page 2] Internet-Draft Path Verification in LSNs March 2026 1. Introduction Low-Earth Orbit (LEO) Satellite Networks (LSNs) are gaining tremendous popularity in recent years, with leading providers like SpaceX and Amazon Kuiper deploying thousands of satellites powered by laser inter-satellite links (ISLs) to provide global Internet services. Starlink, the largest operational LSN today, has launched more than 10,000 LEO satellites and attracted more than 12 million global subscribers. However, unlike static terrestrial infrastructures, LEO satellites continuously orbit the Earth and inevitably traverse uncontrolled regions with potential security threats. These include electromagnetic interference , traffic hijacking, and information leakages through satellite hacking. For satellite network operators (SNOs), it is critical to not only enforce forwarding paths that bypass risk areas, but also verify that actual paths comply with avoidance policies. Existing path verification approaches face significant challenges in dynamic LSNs. Crypto-based methods [CoNext11pv] [SIGCOMM14pv] [sec20pv] require per-hop authentication, imposing high computation overhead on resource-constrained satellites. Delay-based methods [SIGCOMM15pv] [sec17pv] [NDSS19pv] assume linear delay-distance relationships, which do not hold in LSNs due to frequent topology changes [INFOCOM22bg] [CoNext23bg] [HotNets18routing]. This document analyzes the impact of LEO dynamics on existing path verification approaches, demonstrating through case studies on Starlink that delay-based methods suffer from high verification inaccuracy in dynamic satellite environments. We present StarVeri, a path verification framework that specifies a segment-based verification protocol with cryptographic authentication and adaptive delay thresholds to achieve both efficiency and accuracy. 2. Characteristics of LEO Satellite Networks 2.1. Preliminaries for LEO Satellite Networks Today's LSNs like SpaceX's Starlink consist of hundreds to thousands of LEO satellites that work as "routers in space", together with many geo-distributed ground stations connecting satellites and terrestrial network infrastructures. Satellites communicate with ground entities (e.g., ground stations or satellite terminals) via ground-satellite radio links (GSL). Besides, many satellite constellations (e.g., Starlink and Kuiper) leverage high-speed laser inter-satellite links (ISLs) for inter-satellite networking and communication. Satellites are typically organized in a +Grid topology, where each satellite Wu, et al. Expires 3 September 2026 [Page 3] Internet-Draft Path Verification in LSNs March 2026 connects to two neighboring satellites in the same orbit and two in adjacent orbits. As satellites move at a high velocity in various orbital directions over the Earth, the entire LSN experiences frequent topology changes, especially in space-ground connections. LSN traffic between two terrestrial nodes (e.g., from a Starlink's satellite terminal to a remote ground station) is forwarded by a network path constructed by uplink/downlink and ISLs. To deal with the unique LSN topology fluctuation, space routing mechanisms dynamically build and maintain paths for any two terrestrial nodes connected to the LSN. 2.2. Potential Risks in Uncontrolled Areas As satellites move globally, they might enter an uncontrolled risk area, posing routing security threats in LSNs. In this document, we define a "risk area" as a geographical region where malicious attackers may exist and launch the following attacks on satellites above the area: * Information stealing: Attackers in the risk area can eavesdrop on traffic and extract or speculate private data. Attackers in risk areas can eavesdrop on traffic forwarded between satellites. * Traffic hijacking: More powerful attackers in a risk area can hijack the route and cause path inconsistency. They propagate error routing advertisements to allure surrounding satellites to forward packets to them and redirect traffic to specific nodes for censorships, or other man-in-the-middle attacks like packet injection, modification, and counterfeit. Therefore, to avoid the above risks, it is essential for satellite network operators (SNOs) to: (i) apply avoidance policies to force their traffic to bypass potential risk areas, and more importantly, (ii) verify that the actual paths are consistent with the planned avoidance policies in practice. 3. Impact of LEO Dynamics on Path Verification 3.1. Today's Network Path Verification Over the past decade, the network community has had a body of efforts working on network path verification. In particular, existing path verification efforts can be classified into two main categories: crypto-based and delay-based approaches. Wu, et al. Expires 3 September 2026 [Page 4] Internet-Draft Path Verification in LSNs March 2026 3.1.1. Crypto-based path verification One classic path verification approach is to embed the planned path (e.g., a sequence of nodes that build the network path) into the header of each packet. Then intermediate nodes authenticate and update related fields before sending to the next node [CoNext11pv] [SIGCOMM14pv] [sec20pv]. These approaches have three limitations in LSNs. First, each intermediate node needs to perform cryptographic operations like calculating MACs hop by hop, which involves high computation overhead that could be unaffordable for resource- constrained satellites. Second, the increased length of the verification header also leads to extra packet header overhead, resulting in goodput ratio reduction. Third, per-hop authentication inevitably involves additional processing delay on each node. Note that the high mobility of LEO satellites incurs frequent path changes [INFOCOM22bg] [CoNext23bg] [HotNets18routing], if the packet processing delay is too high, the pre-calculated path might be invalid on the route. Although some recent works like PPV [IWQoS18pv] and MASK [ToN23pv] propose probabilistic authentication instead of verifying every packet hop by hop, the computation overhead can be still high when the traffic volume is large. 3.1.2. Delay-based path verification Alibi Routing [SIGCOMM15pv] proposes a new path verification approach, exploiting the key idea that a detour from the planned path to any node in the risk area will breach the maintained delay by incurring significant extra delay. To verify whether a network path from a source (Src) to its destination (Dst) passes through the risk area, Alibi Routing pre-computes a target area that is far away from the risk area where possible verifiable relays (called alibis) are located. It enforces that the path from Src to Dst must pass through the alibis. Because the relay is very far from the risk area, if the Src to Dst path passes through the risk area, the observed end-to-end delay should be significantly higher than the maintained value. However, these approaches are based on a fundamental assumption that the delay between two terrestrial nodes has a linear relationship with their great-circle distance. Although this assumption exists in many scenarios in today's terrestrial Internet [SIGCOMM09linear], it is not applicable in LSNs with highly dynamic topology. An increase in path delay may not necessarily be caused by traversing the risk area but path changes due to topology fluctuation. Wu, et al. Expires 3 September 2026 [Page 5] Internet-Draft Path Verification in LSNs March 2026 3.2. A Case Study: LEO Dynamics Affect the Verification Accuracy We conduct a quantitative analysis to demonstrate how the unique topology fluctuations in LSNs affect the verification accuracy of existing delay-based approaches. Our analysis is based on the real Starlink constellation information and an LSN simulation based on StarryNet [StarryNet]. We build a virtual LSN consisting of 1584 satellites with 72 orbits and 22 satellites per orbit (Starlink Phase 1, Shell 1) and 165 geo-distributed ground stations around the world. We simulate about 2000 city pairs communicating over the LSN using shortest path routing. First, we observe that the linear relationship assumption [SIGCOMM09linear] does not hold in LSNs. By plotting the relationship between great circle distance and Round-Trip Time (RTT) for LSN paths, we find significant scatter and deviation from a linear relationship. On our further investigation, we confirm that the delay increase is caused by frequent topology fluctuations and path changes in LSNs even if the source and destination are static on the ground. Second, we observe the non-linear relationship can lead to inaccuracy for delay-based verification approaches. We simulate the Alibi Routing [SIGCOMM15pv] mechanism and set a static ground relay for each city pair. We calculate the ratio of false positive (FP, i.e., the real path does not traverse the risk area but is considered as passing through it) and false negative (FN, i.e., the opposite of FP) of each city pair in 24 hours with an interval of 1 second. These error ratios are defined as the proportion of the amount of time slots that FP or FN occurs to the total amount of time slots. Figure 1 shows the CDF of error ratios across all city pairs: Wu, et al. Expires 3 September 2026 [Page 6] Internet-Draft Path Verification in LSNs March 2026 CDF 1.0 |-----------//---.----------------------| | // . | 0.8 | // . | | // . | 0.6 | // . | | // . | 0.4 | // . | | // . | 0.2 | // . | | //. | 0.0 +-------|-------|-------|-------|-------| 0.00 0.25 0.50 0.75 1.00 Error Ratios in 24h // FN (False Negative) -- FP (False Positive) Figure 1: CDF of verification error ratios for Alibi Routing in LSNs The results demonstrate that delay-based verification methods suffer from high inaccuracy. As shown in Figure 1, most city pairs experience false negative (FN) ratios around 25% and false positive (FP) ratios between 25-35%, indicating that existing delay-based approaches frequently fail to correctly identify whether paths traverse risk areas. The root cause of this inaccuracy lies in the violation of the linear delay-distance assumption in dynamic LSNs. Unlike terrestrial networks where routing paths remain relatively stable, satellite networks experience continuous topology changes due to orbital motion. When a satellite moves or an ISL switches, the forwarding path changes even though the source and destination remain fixed on the ground. These path changes introduce delay variations that are indistinguishable from detours through risk areas, causing the delay- based verification to produce false alarms or miss actual violations. The fundamental challenge is that delay increases in LSNs can result from either legitimate topology changes or malicious path deviations, making delay alone an unreliable verification metric. Therefore, accomplishing accurate path verification in dynamic LSN environments requires new approaches that account for topology dynamics while maintaining verification efficiency. 4. Path Verification Framework for LEO Satellite Networks Wu, et al. Expires 3 September 2026 [Page 7] Internet-Draft Path Verification in LSNs March 2026 4.1. Framework Overview StarVeri provides satellite network operators (SNOs) with the ability to verify path compliance between planned packet delivery paths and actual forwarding paths in dynamic LSN environments. The framework can be deployed on existing Path-Aware Networking (PAN) or source routing architectures (e.g., Segment Routing [RFC8402]) that allow path enforcement through pre-calculated satellite relays. StarVeri adopts a segment-based verification approach that addresses the limitations of existing methods. At a high level, to verify a network path from source (Src) to destination (Dst), StarVeri uses a collection of dynamic satellite relays to split the entire path into a series of consecutive segments. Thus, verifying the entire path is equivalent to verifying each segment path. To reduce verification overhead, StarVeri only requires relays (instead of all nodes on the path) to authenticate forwarded packets. While the end-to-end delay of a network path fluctuates due to LSN dynamics, the delay fluctuation of a segment (e.g., between two adjacent relays) is less dramatic than the delay fluctuation of the entire path. StarVeri verifies each segment by comparing the real inter-relay delay with an estimated upper bound. The framework consists of three key components: * SNO Operation Center: Calculates and distributes relay configurations to end users * Satellite Relays: Selected satellites that authenticate forwarded packets and verify segment paths * End Nodes (Src/Dst): Source initiates verification fields; destination performs final path validation Figure 2 illustrates the overall architecture: Wu, et al. Expires 3 September 2026 [Page 8] Internet-Draft Path Verification in LSNs March 2026 +---------------------------+ +---------------------------+ | Relay Configuration | | Inter-Relay Verification | | | | | | - Relay Selection | | - Segment Probing | | - Threshold Calculation | | - Adaptive Threshold | | - SNO Operation Center | | - Relay Authentication | +---------------------------+ +---------------------------+ | | | (1) Relay Config | (2) Segment | via Secure Channel | Verification v v +-------+ +-------+ | Src | X X X X X X X X X X | Dst | |(sat_s)| X Risk Area X X |(sat_d)| +-------+ X X X +-------+ | X X X X X X X X X X ^ | | | Segment 1 | Segment 3 v Segment 2 | Relay1 ----------------------------> Relay2 (r_1) (r_2) | | v v [Verify & Update MAC] [Verify & Update MAC] (3) Final Verification: Dst verifies all relay MACs and the last segment Figure 2: StarVeri Architecture Overview 4.2. Verification Workflow This section describes the core protocol mechanisms. The verification workflow for each communication pair (Src, Dst) and a given risk area proceeds as follows: (1) Relay configuration: The SNO operation center calculates relay configurations and estimates segment detour delay thresholds based on predictable satellite trajectories and dynamic LSN topology. Once decided, the operation center delivers the relay configuration to Src via a secure channel. (2) Intra-segment state probing: Each relay (including sat_d) periodically sends probing packets to its previous relay to measure the current segment delay. Probing packets are authenticated using shared symmetric keys to prevent tampering. Wu, et al. Expires 3 September 2026 [Page 9] Internet-Draft Path Verification in LSNs March 2026 (3) Authentication fields initiation: Before packet departure, Src inserts the corrected sending timestamp, hash value, and relay authentication fields (AUTH) in the packet header. (4) Relay-based segment verification: When a relay receives a packet, it verifies the segment path based on its probing ground truth and detour threshold. If the packet does not traverse the risk area, the relay computes a MAC value and updates its corresponding AUTH field with the timestamp. (5) Destination verification: After receiving a packet, Dst verifies the packet's source, AUTH fields updated by relays, and the last segment path to determine whether the packet bypassed the risk area. 4.2.1. Packet header format Before packet departure, Src constructs the verification header to enable segment-based path verification. This header carries authentication information that will be progressively updated by each relay along the path, allowing Dst to verify that the packet has bypassed the risk area through the designated relay sequence. The verification header structure is shown in Figure 3. 0 32-bit 64-bit +--------------+ | | | | IP header | -> +----------+-----------+ +--------------+ | | HASH | ts_0 | | PATH | | +----------+-----------+ +----------------+ +--------------+ | | r_1 | delta_1 | | relay_1's | | AUTH |--| +----------+-----------+ | | +--------------+ | | ts_1 | MAC_Kr1 | | field | | Payload | | +----------+-----------+ +----------------+ +--------------+ | | ... | | +----------+-----------+ +----------------+ * n relays totally | | delta_n+1| ts_d | | sat_d's fields | -> +----------+-----------+ +----------------+ Figure 3: The AUTH header structure of StarVeri The verification header consists of the following components: * HASH (4 bytes): Hash value computed as H(Payload||PATH||\Delta||ts_0||RE)[0:4] using SHA-256 and truncated to 4 bytes. Here, PATH is the relay sequence, \Delta is the detour threshold vector, and RE is the risk area identifier. Wu, et al. Expires 3 September 2026 [Page 10] Internet-Draft Path Verification in LSNs March 2026 * Initial Timestamp ts_0 (8 bytes): Corrected sending time ts_0 = ts_{send} + D_{access} + \alpha, where ts_{send} is the actual sending time, D_{access} is the access link delay, and \alpha is a clock synchronization offset. * AUTH Chain: Reserved fields for relay authentication. The AUTH chain contains n+1 entries: n entries for relays and one entry for destination sat_d. For each relay r_i (where i = 1, 2, ..., n), the AUTH entry contains: - Relay ID (r_i, 2 bytes): Identifier of the relay - Detour threshold (\delta_i, 2 bytes): Maximum acceptable detour delay from previous node to this relay, i.e., \delta_{r_{i-1},r_i} where r_0 denotes Src - Timestamp (ts_i, 8 bytes): Time when the relay processes the packet - MAC (4 bytes): Message Authentication Code MAC_{K_{r_i}}(HASH||ts_i||r_i)[0:4] using HMAC-SHA256 [RFC2104] [RFC6234], truncated to 4 bytes For destination sat_d, the AUTH entry contains: - Detour threshold (\delta_{n+1}, 2 bytes): Maximum acceptable detour delay from last relay r_n to destination, i.e., \delta_{r_n,d} - Timestamp (ts_d, 8 bytes): Time when destination receives the packet 4.2.2. Relay verification procedure When a relay r_i receives a packet, it performs the following verification steps: 1. Check that AUTH_{i-1} has been properly updated by the previous relay. If not, the packet is dropped. 2. Verify segment delay: Check that ts_i - ts_{i-1} \leq \delta_{r_{i-1},r_i} + dt_{r_{i-1},r_i}, where: * \delta_{r_{i-1},r_i}: Detour threshold provided by SNO operation center * dt_{r_{i-1},r_i}: Probed segment delay from periodic probing If the delay exceeds this threshold, the packet is dropped as it may have traversed the risk area. 3. If verification passes, the relay updates its AUTH entry and forwards the packet: * Record current timestamp ts_i * Compute MAC: MAC_{K_{r_i}}(HASH||ts_i||r_i)[0:4] using HMAC * Update AUTH_i with: relay ID (r_i), detour threshold (\delta_i), timestamp (ts_i), and MAC * Forward packet to the next hop according to the PATH field Wu, et al. Expires 3 September 2026 [Page 11] Internet-Draft Path Verification in LSNs March 2026 4.2.3. Destination verification procedure Upon receiving a packet, Dst performs the following verifications in order: 1. Source authentication: Verify the packet source using existing authentication mechanisms (out of scope for this document). 2. Integrity check: Recompute HASH using SHA-256 and compare with the value in the packet header. If they do not match, the packet is dropped. 3. Relay chain validation: For each relay r_i in the AUTH chain, authenticate the MAC using HMAC with the shared session key K_{r_i}. If any MAC validation fails, the packet is dropped. 4. Last segment verification: Check that ts_d - ts_n \leq \delta_{r_n,d} + dt_{r_n,d}, where r_n is the last relay. If this check fails, the packet is dropped. If all verifications pass, Dst accepts the packet as having successfully bypassed the risk area. 4.3. Supporting Mechanisms This section describes supporting mechanisms that enable the verification protocol. These mechanisms are implementation-specific and out of scope for standardization, but are provided for informational purposes. 4.3.1. Relay configuration distribution The SNO operation center distributes relay configurations to Src via a secure channel. The configuration contains: - Relay sequence: [r_1, r_2, ..., r_n] - Detour thresholds: [\delta_{s,r_1}, \delta_{r_1,r_2}, ..., \delta_{r_n,d}] - Validity period: Time range during which this configuration is valid The specific relay selection algorithm is implementation-specific. Different approaches can be used to select relays that minimize detour delay while ensuring verifiability and avoiding risk areas. Wu, et al. Expires 3 September 2026 [Page 12] Internet-Draft Path Verification in LSNs March 2026 4.3.2. Session key negotiation When a path changes or a new session begins, end users, relays, and SNO negotiate session keys for authentication. Session key establishment is out of scope for this document. Existing key derivation methods such as DRKey or other secure key distribution mechanisms can be used. 4.3.3. Intra-segment probing Each relay periodically (e.g., every tens of seconds) sends probing packets to its previous relay to measure the current segment delay. The probing mechanism is implementation-specific. A typical implementation includes: * Probing packet format: Contains a nonce, timestamp, and hop-by-hop MACs for authentication * Probing reply: Contains the probe ID, measured RTT, and authentication MACs * Adaptive threshold computation: The measured delay dt_{r_{i-1},r_i} is used together with the detour threshold \delta_{r_{i-1},r_i} to determine the segment delay upper bound Alternative probing approaches or different probing frequencies can be used based on network conditions. 5. Conclusion This document specifies StarVeri, a path verification framework designed for the unique challenges of LEO satellite networks. StarVeri addresses the limitations of existing verification approaches by introducing a segment-based verification protocol that enables efficient and accurate path verification in highly dynamic satellite environments. The framework defines a verification protocol based on relay-divided segments. The protocol specifies: (i) a verification header format that carries authentication information progressively updated by each relay, (ii) relay verification procedures that check segment delays and update authentication fields, and (iii) destination verification procedures that validate the complete relay chain and path compliance. By verifying paths through segments rather than hop-by- hop, StarVeri reduces computation overhead on resource-constrained satellites while maintaining verification accuracy. Wu, et al. Expires 3 September 2026 [Page 13] Internet-Draft Path Verification in LSNs March 2026 StarVeri provides satellite network operators with a practical mechanism to enforce and verify risk-avoidance routing policies, contributing to the security and reliability of emerging global satellite Internet services. 6. Security Considerations This document does not represent a change to any aspect of the TCP/IP protocol suite and therefore does not directly impact Internet security. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/ RFC2104, February 1997, https://www.rfc-editor.org/info/rfc2104 (https://www.rfc-editor.org/info/rfc2104) [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, https://www.rfc-editor.org/info/ rfc6234 (https://www.rfc-editor.org/info/rfc6234) [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, https://www.rfc-editor.org/info/rfc8402 (https://www.rfc- editor.org/info/rfc8402) 8.2. Informative References [CoNext11pv] "OPT: On-demand Path Tracing", ACM CoNext, 2011 [SIGCOMM14pv] "ICING: In-band Control for Inter-Domain Routing", ACM SIGCOMM, 2014 [sec20pv] "Secure Path Validation", Security Conference, 2020 [SIGCOMM15pv] Levin, D., Lee, Y., Valenta, L., Li, Z., Lai, V., Lumezanu, C., Spring, N., and B. Bhattacharjee, "Alibi Routing", Proceedings of the 2015 SIGCOMM, pp. 611-624, 2015 [sec17pv] Li, Z., Herwig, S., and D. Levin, "DeTor: Provably Avoiding Geographic Regions in Tor", 26th USENIX Security Symposium, pp. 343-359, 2017 [NDSS19pv] Kohls, K., Jansen, K., Rupprecht, D., Holz, T., and C. Pöpper, "On the Challenges of Geographical Avoidance for Tor", Network and Distributed System Security Symposium, 2019 Wu, et al. Expires 3 September 2026 [Page 14] Internet-Draft Path Verification in LSNs March 2026 [INFOCOM22bg] "LEO Satellite Network Background", IEEE INFOCOM, 2022 [CoNext23bg] Tanveer, H., Puchol, M., Singh, R., Bianchi, A., and R. Nithyanand, "Making Sense of Constellations: Methodologies for Understanding Starlink's Scheduling Algorithms", Companion of the 19th International Conference on Emerging Networking EXperiments and Technologies, pp. 37-43, 2023 [HotNets18routing] Handley, M., "Delay is Not an Option: Low Latency Routing in Space", Proceedings of the 17th ACM Workshop on Hot Topics in Networks, pp. 85-91, 2018 [IWQoS18pv] "PPV: Probabilistic Path Verification", IEEE IWQoS, 2018 [ToN23pv] "MASK: Masked Authentication for Scalable Path Verification", IEEE/ACM Transactions on Networking, 2023 [SIGCOMM09linear] "On the Linear Relationship between Delay and Distance", ACM SIGCOMM, 2009 [StarryNet] "StarryNet: LEO Satellite Network Simulator", 2023 9. Acknowledgments Thanks to all of the contributors. Authors' Addresses Qian Wu Tsinghua University 30 ShuangQing Ave Beijing 100089 China Email: wuqian@cernet.edu.cn Yuxuan Weng Tsinghua University 30 ShuangQing Ave Beijing 100089 China Email: wengyx25@mails.tsinghua.edu.cn Zeqi Lai Tsinghua University 30 ShuangQing Ave Beijing 100089 China Email: zeqilai@tsinghua.edu.cn Wu, et al. Expires 3 September 2026 [Page 15] Internet-Draft Path Verification in LSNs March 2026 Hewu Li Tsinghua University 30 ShuangQing Ave Beijing 100089 China Email: lihewu@cernet.edu.cn Wu, et al. Expires 3 September 2026 [Page 16]