Path Verification in LEO Satellite Networks
draft-wu-tvr-path-verification-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Qian Wu , Yuxuan Weng , Zeqi Lai , Hewu Li | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-tvr-path-verification-00
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]