REVIEW 4 major objections 4 minor 43 references
Data-Plane Telemetry to Mitigate Long-Distance BGP Hijacks
T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash
Pith's one-line read A long-distance BGP hijack cannot hide: its added delay is unavoidable, and this paper builds a switch detector that flags any prefix whose minimum RTT crosses a speed-of-light lower bound, claiming zero false negatives by design.
desk verdict A serious systems paper with a real prototype, but the zero-false-negative guarantee breaks against the paper's own surgical-attack threat model because the per-prefix minRTT signal is blind to partial hijacks. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing object is the absolute threshold $\tau^*_{mid}$: a lower bound on the round-trip time of any attack route, computed as the shortest great-circle path through the threat region divided by the speed of light in fiber ($c_f = 2c/3 \approx 199.86$ km/ms), using geolocation data for the source, destination, and threat coordinates. The argument is that since a hijack reroutes all traffic to a prefix through the attacker, no RTT measured during the attack can fall below $\tau^*_{mid}$, which makes crossing it a sufficient condition for declaring an attack. Detection itself is carried by a two-window changepoint algorithm: per-prefix RTT samples are aggregated into tumbling windows, the minimum in each window is tracked, and an attack is declared when the minRTT crosses $\tau^*_{mid}$ between consecutive windows and rises by at least a surge threshold $\lambda$; windows with fewer than five samples are treated as invalid. Noise is handled by min-filtering and prefix-level aggregation, and the false-positive cost is capped by an auto-correction loop that actively probes a blocked prefix and unblocks it as soon as RTT falls back below $\tau^*_{mid}$.
What would settle it
Run HiDe against a real interception attack whose measured path RTT is below the auto-tuned $\tau^*_{mid}$, for example a hijack to an anycast prefix, a path crossing a satellite or free-space link, or an attacker IP that the geolocation databases misplace by a few hundred kilometers; if the attack is not flagged, the zero-false-negative claim fails. A cheaper check is to take latency time series from past publicly documented long-distance hijacks and count how many would actually have crossed the threshold computed from today's geolocation data.
Extended reading notes
Core claim
The central claim is that a carefully tuned changepoint detector on per-prefix minimum RTT can catch long-distance BGP interception attacks with zero false negatives by design. For each protected prefix and each user-specified threat region, HiDe computes $\tau^*_{mid}$, the minimum possible mid-attack round-trip time, as the great-circle distance from the source to the attacker's region to the destination divided by the speed of light in fiber ($c_f = 2c/3 \approx 199.86$ km/ms). Because a hijack moves every packet to the targeted prefix onto the attacker's path, no RTT sample observed during the attack can be smaller than this bound, so HiDe's two-window detector flags a prefix whenever the windowed minRTT crosses $\tau^*_{mid}$ and surges by at least $\lambda$; the paper calls the crossing an absolute proof of attack, and the guarantee against false negatives follows from the bound being a true lower bound. The claim is supported three ways: a country-pair analysis showing that optimal (least detectable) attacks still push mid-attack RTT well above pre-attack RTT for most of the world, a faithful simulation on real campus traffic showing low false positives and fast self-correction, and live ethically conducted interception attacks detected within 0.5 seconds.
Load-bearing premise
The zero-false-negative guarantee holds only if $\tau^*_{mid}$ is a true lower bound on the delay of every real attack route, which assumes the geolocation databases locate the source, destination, and threat region correctly and that no path is faster than two-thirds of the speed of light along the great-circle distance; a wrong location (anycast prefixes, country-level precision, satellite-backed paths) would set the threshold too high and let a genuine long-distance attack pass unflagged.
Editorial extensions
If this is right
- Detection time drops from the minutes that BGP control-plane convergence and route monitoring take to roughly half a second, because the surge is visible in the first packets that traverse the diverted path.
- Stealth techniques that hide a hijack from BGP monitors, such as community-based surgical announcements with a small blast radius, cannot hide the delay increase, so HiDe catches attacks that control-plane systems miss by construction.
- Operators get a quantitative planning tool: the country-pair analysis tells them which of their prefixes are defensible against which threat regions, and how the surge threshold $\lambda$ trades coverage against false positives.
- An always-on deployment is operationally harmless: false positives are below 0.012% on real campus traffic, and each one is corrected automatically in a median of 0.75 seconds without human intervention.
- Non-TCP traffic to a protected prefix is covered for free, because any TCP flow sharing the prefix's path provides the RTT samples that reveal the diversion.
Reading between the lines
- The zero-false-negative claim is a property of the threshold, not of the measurement: if geolocation or the $2c/3$ fiber-speed assumption is wrong in the field, the guarantee silently degrades to a probabilistic one, so a deployment should monitor the margin between benign minRTTs and $\tau^*_{mid}$ and treat close calls as a warning that the bound is not safe.
- The same lower-bound logic extends beyond country-scale threats: any polygon-defined region yields its own $\tau^*_{mid}$, so the scheme could defend against city- or data-center-level diversion, and operators could substitute a measured percentile of latency for the absolute bound when they prefer broader coverage over the strict guarantee.
- An attacker who cannot shorten the physical detour still has one lever: inflate pre-attack minRTTs, for example by inducing congestion, to shrink the observed surge; min-filtering should blunt this, but the paper does not test an adversary who optimizes against the detector itself.
- Because HiDe protects only the edge where it is deployed, it is a complement rather than a replacement for global control-plane monitoring; the two together would cover both the short-distance attacks that never cross the delay threshold and the long-distance ones that evade route monitors.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This paper studies detection of long-distance BGP interception attacks using propagation-delay changes. It first conducts a large-scale geometric feasibility analysis over 258 countries, reporting that even optimal (least-detectable) cross-country attacks produce RTT deviations above 5 ms for 97% of country pairs under speed-of-light assumptions and for 91%/86% of pairs under two real-measurement datasets. It then presents HiDe, a programmable-switch system that passively measures per-prefix minRTT in tumbling windows and flags a hijack when the minRTT crosses a geolocation-derived absolute lower bound tau*_mid and surges by at least lambda. HiDe is implemented in P4 on Tofino2, evaluated by faithful simulation on a 12-hour campus trace (19 billion packets) for false-positive rate and downtime, and validated with ethically conducted PEERING-based hijacks of iperf3 and Bitcoin traffic, with detection reported within 0.5 seconds.
Significance. If the central claims hold, this is a significant systems contribution: it shows that a data-plane-only latency signal, which the attacker cannot hide, can be turned into a line-rate detector and automatic mitigation on commodity hardware, with a clean geometric lower-bound argument and a small parameter set. The evaluation is substantial: 19B packets/7.5M flows of trace data, two real-world ethical hijacks over PEERING, Tofino2 resource measurements, and a plan to release code and anonymized latency data. The 'zero false negatives by design' claim is strong and falsifiable, which makes the correctness conditions worth scrutinizing. The paper's main limitations are that the headline coverage figures are model extrapolations rather than measured detection rates, and the threat model's surgical-attack component is not matched by the per-prefix aggregation signal.
major comments (4)
- [§2.2, §4, §5.2, §5.4] The threat model explicitly includes stealthy surgical interception attacks that use BGP-community manipulation to limit the blast radius of the announcement (Birge-Lee et al., cited as [12]). The detection signal, however, is the minimum RTT over all flows to a destination prefix per time window (§5.2, §5.4), and the zero-false-negative argument in §5.1 relies on the premise in §4 that 'during a hijack, all traffic to a victim prefix must traverse the longer path via the attacker.' Under a surgical attack only a subset of sources, or only one upstream of a multi-homed prefix, is diverted; the remaining flows to the same prefix continue to yield low RTT samples, so the per-prefix minimum stays at the benign level and neither the absolute-threshold crossing nor the surge condition fires. This is an internal mismatch between the aggregated signal and the attack model, not a data-quality issue. The live experiments do not resolve it: the §8.2 Bitcoin experiment installs monitoring rules only for European nodes, and the iperf3 experiment measures a complex proxied path, so neither tests the per-prefix minRTT detector under a mixed hijacked/unhijacked flow mix; §8.1 injects no attacks and therefore cannot measure false negatives.
- [§5.1] The claimed zero-false-negative guarantee rests on the auto-tuned absolute threshold tau*_mid being a true lower bound on the mid-attack RTT. This requires the geolocations of source, destination, and the threat-region boundary to be correct. Public geolocation databases (IPinfo, MaxMind) are known to be inaccurate for anycast IPs, mobile endpoints, and country-level precision; if the computed coordinates are wrong, tau*_mid can be too high, and a real attack with a shorter delay will not cross the threshold, breaking the guarantee. The paper acknowledges in §9 that free-space and satellite paths can be faster than c_f and handles them by exclusion, but geolocation error is not stress-tested anywhere in the evaluation. This is a load-bearing correctness risk for the zero-false-negative claim, not a presentation detail.
- [§8.2] The live iperf3 validation is circular with respect to the auto-tuning claim. The absolute threshold is set to 199 ms, a value estimated by traceroute during the attack ('Using multiple runs of traceroute, we estimate the lower bound of RTT as approx. 190.5 ms before attack and 199 ms during attack (absolute threshold)'). This is not the §5.1 tau*_mid computed from geolocation and speed-of-light; it is calibrated on the very attack the detector is supposed to detect. The experiment therefore demonstrates only that a threshold placed at the attack-time RTT triggers detection; it does not validate the auto-tuning component or the zero-false-negative guarantee. The Bitcoin experiment reports 'based on our calculations' without showing the threshold derivation, so it provides only weak evidence that the auto-tuned threshold is correct.
- [§3.5, Abstract] The 91% and 86% coverage figures are model extrapolations, not measured detection rates. They are obtained by binning measured minOWDs by great-circle distance, fitting p25 and p75 regression lines per bin, and then substituting the p75 line for pre-attack delay and the p25 line for mid-attack delay into the geometric optimal-attack formula. No real attack is replayed on the trace, and no validation of the regression model or confidence intervals is reported. The abstract's 'at least 25%' condition is not defined in §3.5, which uses an absolute tau*_deviation >= 5 ms criterion; the two statements should be reconciled. The coverage numbers should be labeled as model-based estimates rather than measured detection rates, both in §3 and in the abstract.
minor comments (4)
- [§5.2] The last sentence of §5.2 says tracking minRTTs in non-overlapping tumbling windows 'requires only per-flow state,' but the system described in §6.2 maintains per-prefix state; this should be corrected to per-prefix state.
- [Figure 12a] The y-axis of Figure 12a begins at 190 ms, which visually magnifies a roughly 9 ms RTT increase; a full-scale plot or an explicit statement of the actual before/after deltas in the text would make the surge easier to assess.
- [References] References [28] and [29] are the same paper ('On the Effectiveness of BGP Hijackers That Evade Public Route Collectors') and should be merged into a single entry.
- [§3.5] The dataset-cleaning step discards flows whose minRTT indicates distances shorter than those permitted by reported geolocations; since geolocation accuracy is load-bearing for tau*_mid in §5.1, the number of discarded flows/prefixes and the effect on the resulting coverage curves should be reported.
Circularity Check
Live iperf3 validation sets the absolute threshold from traceroute RTTs measured during the attack, making the reported 'almost immediate' detection a by-construction fit; the geo-lower-bound design is otherwise self-contained.
-
fitted input called prediction
[Section 8.2, 'Mitigating attacks on iperf3 traffic' (live interception attack detection)]
"Using multiple runs of traceroute, we estimate the lower bound of RTT as approx. 190.5 ms before attack and 199 ms during attack (absolute threshold). We set the window size to 0.25 sec and the surge threshold to 5 ms. Based on the minimum RTTs (orange triangles), we detect the attack almost immediately (red star)."
Here the absolute threshold—the detector's tau*_mid, specified in Section 5.1 as a geo-computed speed-of-light lower bound—is instead read off from traceroute RTTs of the very path under attack, including the mid-attack value of 199 ms. The attack raises minRTT to about 199 ms, so the threshold is reached by construction; the 8.5 ms gap between the fitted traceroute values also exceeds the chosen 5 ms surge threshold, guaranteeing that both surge conditions fire. This live experiment therefore shows only that the detector fires when its threshold is set to the observed attack RTT; it does not validate the auto-tuning computation from geolocation, and the claimed 'almost immediate detection' is a fitted input rather than an independent prediction.
full rationale
HiDe's central mechanism—computing tau*_mid as a speed-of-light lower bound on any attack path from a user-specified threat region, then detecting a crossing of that bound in per-prefix minRTT—is a self-contained first-principles derivation under the paper's stated assumptions (all traffic to the prefix traverses the attacker, and geolocations are correct). The trace-based false-positive evaluation and the Bitcoin live experiment use thresholds set independently of the attacks (by calculation or by geo-derived bounds), so the overall design is not merely a fit. The one clear circular step is the iperf3 validation, where the absolute threshold is taken from traceroute RTTs measured during the same attack, making the detection a tautology for that experiment. This is a partial, validation-level circularity rather than a collapse of the central claim. Separately, there is a non-circular correctness gap: the threat model explicitly includes surgical BGP-community-based interception that can divert only a subset of flows, while the detection signal is the per-prefix minimum RTT; if even one benign flow to the prefix remains, the minRTT can stay below tau*_mid and the zero-false-negative guarantee fails. That is an internal threat-model mismatch, not a circular derivation, so it does not affect the circularity score.
Assumptions & free parameters
free parameters (5)
- surge threshold lambda =
5 ms (default), evaluated from 5 to 75 ms
- absolute threshold tau*_mid in live experiments =
199 ms (iperf3), 135 ms (Bitcoin)
- tumbling window size W =
0.25 s (iperf3), 0.25/0.5 s (design)
- minimum samples per valid window =
5
- p25/p75 regression lines for delay-per-distance =
fit to campus and MLab datasets
assumptions (5)
- domain assumption Great-circle distance divided by c_f = 2c/3 is a lower bound on the propagation delay of any real network path between two hosts.
- domain assumption During a BGP interception attack, all traffic to the victim prefix traverses the attacker's route, so no RTT sample can be shorter than the minimum delay of that route.
- domain assumption IP geolocation databases (IPinfo, MaxMind) and the Natural Earth country boundaries correctly locate the source, destination, and threat regions.
- domain assumption The 12-hour campus trace contains no long-distance interception attacks, so any HiDe detection in the trace is a false positive.
- domain assumption TCP data-ACK matching yields RTT samples that reflect propagation delay plus bounded noise.
Cite this review
Pith. "Pith review of Data-Plane Telemetry to Mitigate Long-Distance BGP Hijacks." pith.science (2026). https://pith.science/paper/U76LZXQL
@misc{pith2026250714842,
author = {Pith},
title = {Pith review of: Data-Plane Telemetry to Mitigate Long-Distance BGP Hijacks},
year = {2026},
howpublished = {\url{https://pith.science/paper/U76LZXQL}},
note = {Machine review of arXiv:2507.14842}
}
read the original abstract
Poor security of Internet routing enables adversaries to divert user data through unintended infrastructures (hijack). Of particular concern -- and the focus of this paper -- are cases where attackers reroute domestic traffic through foreign countries, exposing it to surveillance, bypassing legal privacy protections, and posing national security threats. Efforts to detect and mitigate such attacks have focused primarily on the control plane while data-plane signals remain largely overlooked. In particular, change in propagation delay caused by rerouting offers a promising signal: the change is unavoidable and the increased propagation delay is directly observable from the affected networks. In this paper, we explore the practicality of using delay variations for hijack detection, addressing two key questions: (1) What coverage can this provide, given its heavy dependence on the geolocations of the sender, receiver, and adversary? and (2) Can an always-on latency-based detection system be deployed without disrupting normal network operations? We observe that for 86% of victim-attacker country pairs in the world, mid-attack delays exceed pre-attack delays by at least 25% in real deployments, making delay-based hijack detection promising. To demonstrate practicality, we design HiDe, which reliably detects delay surges from long-distance hijacks at line rate. We measure HiDe's accuracy and false-positive rate on real-world data and validate it with ethically conducted hijacks.
Figures
Figures from the paper (12 more)
Reference graph
Works this paper leans on
-
[12]
Henry Birge-Lee, Liang Wang, Jennifer Rexford, and Prateek Mittal. 2019. Sico: Surgical interception attacks by manipulating BGP communities. InACM SIGSAC Conference on Computer and Communications Security . 431–448
work page 2019
-
[1]
[n. d.]. KlaySwap crypto users lose funds after BGP hijack. https:// therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/
-
[2]
[n. d.]. PEERING: The BGP Testbed. https://peering .ee.columbia.edu/about/
-
[3]
[n. d.]. Russian-controlled telecom hijacks financial services’ Internet traf- fic. https://arstechnica.com/information-technology/2017/04/russian-controlled- telecom-hijacks-financial-services-internet-traffic/
work page 2017
-
[4]
[n. d.]. Thousandeyes. https://www .thousandeyes.com/resources/detecting- hijacks-and-leaks-webinar
-
[5]
Aftab Siddiqui. [n. d.]. Public DNS in Taiwan the latest victim to BGP hijack. https: //manrs.org/2019/05/public-dns-in-taiwan-the-latest-victim-to-bgp-hijack/
work page 2019
-
[6]
Anurag Agrawal and Changhoon Kim. 2020. Intel tofino2–a 12.9 tbps p4- programmable ethernet switch. In 2020 IEEE Hot Chips 32 Symposium (HCS) . IEEE Computer Society, 1–32
work page 2020
-
[7]
Andree Toonk. [n. d.]. How Hacking Team Helped Italian Special Operations Group with Routing Hijack. https://bgpmon .net/how-hacking-team-helped- italian-special-operations-group-with-bgp-routing-hijack/
Show all 43 references
-
[8]
2017.BGPsec Protocol Specification
Rob Austein, Steven Bellovin, Russ Housley, Stephen Kent, Warren Kumari, Doug Montgomery, Chris Morrow, Sandy Murphy, Keyur Patel, John Scudder, Samuel Weiler, Matthew Lepinski, and Kotikalapudi Sriram. 2017.BGPsec Protocol Specification. RFC 8205
2017
-
[9]
bgphijack [n. d.]. $83k in bitcoins ’stolen’ through BGP hijack. https://www.virusbulletin.com/blog/2014/08/83k-bitcoins-stolen-through- bgp-hijack/
2014
-
[10]
Henry Birge-Lee, Maria Apostolaki, and Jennifer Rexford. 2024. Global BGP Attacks that Evade Route Monitoring. arXiv preprint arXiv:2408.09622 (2024)
2024 arXiv
-
[11]
Henry Birge-Lee, Yixin Sun, Anne Edmundson, Jennifer Rexford, and Prateek Mittal. 2018. Bamboozling certificate authorities with{BGP}. In 27th USENIX Security Symposium (USENIX Security 18) . 833–849
2018
-
[13]
Mihai Budiu and Chris Dodd. 2017. The p416 programming language. ACM SIGOPS Operating Systems Review 51, 1 (2017), 5–14
2017
-
[14]
Tobias Bühler, Alexandros Milolidakis, Romain Jacob, Marco Chiesa, Stefano Vissicchio, and Laurent Vanbever. 2023. Oscilloscope: Detecting BGP Hijacks in the Data Plane. arXiv:2301.12843 (2023)
2023 arXiv
-
[15]
Bush and R
R. Bush and R. Austein. 2013. The Resource Public Key Infrastructure (RPKI) to Router Protocol. RFC 6810
2013
-
[16]
celer [n. d.]. Celer Bridge incident analysis. https://www.coinbase.com/blog/ celer-bridge-incident-analysis
-
[17]
Xiaoqi Chen, Hyojoon Kim, Javed M Aman, Willie Chang, Mack Lee, and Jen- nifer Rexford. 2020. Measuring TCP round-trip time in the data plane. In ACM SIGCOMM Workshop on Secure Programmable Network Infrastructure . 35–41
2020
-
[18]
Natural Earth Data. 2011. Natural Earth Data-Free vector and raster map data. http://www. naturalearthdata. com (accessed 10.12.2024) (2011)
2011
-
[19]
Sharon Goldberg. 2014. Why is it taking so long to secure internet routing? Commun. ACM 57, 10 (2014), 56–63
2014
-
[20]
Dan Goodin. 2018. Strange snafu misroutes domestic US Internet traffic through China Telecom. Ars Technica 6 (2018)
2018
-
[21]
Rahul Hiran, Niklas Carlsson, and Nahid Shahmehri. 2015. Crowd-based detec- tion of routing anomalies on the Internet. In 2015 IEEE Conference on Communi- cations and Network Security (CNS) . IEEE, 388–396
2015
-
[22]
Thomas Holterbach, Edgar Costa Molero, Maria Apostolaki, Alberto Dainotti, Stefano Vissicchio, and Laurent Vanbever. 2019. Blink: Fast connectivity recovery entirely in the data plane. In USENIX Symposium on Networked Systems Design and Implementation (NSDI 19) . 161–176
2019
-
[23]
Thomas Holterbach, Stefano Vissicchio, Alberto Dainotti, and Laurent Vanbever
-
[24]
Dave Levin, Youndo Lee, Luke Valenta, Zhihao Li, Victoria Lai, Cristian Lumezanu, Neil Spring, and Bobby Bhattacharjee. 2015. Alibi routing. In ACM SIGCOMM. 611–624
2015
-
[25]
Jun Li, Toby Ehrenkranz, and Paul Elliott. 2012. Buddyguard: A buddy system for fast and reliable detection of IP prefix anomalies. In 2012 20th IEEE International Conference on Network Protocols (ICNP) . IEEE, 1–10
2012
-
[26]
LLC MaxMind. 2006. GeoIP
2006
-
[27]
(2024-12-01 – 2024-12-05)
Measurement Lab. (2024-12-01 – 2024-12-05). The M-Lab NDT Data Set. https://measurementlab .net/tests/ndt. Bigquery table measurement-lab.ndt.download
2024
-
[28]
Alexandros Milolidakis, Tobias Bühler, Kunyu Wang, Marco Chiesa, Laurent Vanbever, and Stefano Vissicchio. 2023. On the Effectiveness of BGP Hijackers That Evade Public Route Collectors. IEEE Access 11 (2023), 31092–31124
2023
-
[29]
Alexandros Milolidakis, Tobias Bühler, Kunyu Wang, Marco Chiesa, Laurent Vanbever, and Stefano Vissicchio. 2023. On the Effectiveness of BGP Hijackers That Evade Public Route Collectors. IEEE Access 11 (2023), 31092–31124. https: //doi.org/10.1109/ACCESS.2023.3261128
2023
-
[30]
Shaun Nichols. [n. d.]. AWS DNS network hijack turns MyEtherWal- let into ThievesEtherWallet. https://www .theregister.com/2018/04/24/ myetherwallet_dns_hijack/
2018
-
[31]
Rasmus Pagh and Flemming Friche Rodler. 2004. Cuckoo hashing. Journal of Algorithms 51, 2 (2004), 122–144
2004
-
[32]
Reischuk, and Laurent Chuat
Adrian Perrig, Pawel Szalachowski, Raphael M. Reischuk, and Laurent Chuat
-
[33]
RIPE NCC. [n. d.]. YouTube Hijacking: A RIPE NCC RIS case study. https://www.ripe.net/publications/news/youtube-hijacking-a-ripe-ncc-ris- case-study/
-
[34]
Springer Verlag
SCION: A Secure Internet Architecture . Springer Verlag
-
[35]
Brandon Schlinker, Todd Arnold, Italo Cunha, and Ethan Katz-Bassett. 2019. PEERING: Virtualizing BGP at the Edge for Research. In ACM CoNEXT. Orlando, FL
2019
-
[36]
Andrei Robachevsky. 2019. “Routing security getting better, but no reason to rest!
2019
-
[37]
Pavlos Sermpezis, Vasileios Kotronis, Petros Gigis, Xenofontas Dimitropoulos, Danilo Cicalese, Alistair King, and Alberto Dainotti. 2018. ARTEMIS: Neutralizing BGP hijacking within a minute. IEEE/ACM Transactions on Networking 26, 6 (2018), 2471–2486
2018
-
[38]
Satadal Sengupta, Hyojoon Kim, and Jennifer Rexford. 2022. Continuous in- network round-trip time monitoring. In Proceedings of the ACM SIGCOMM 2022 Conference. 473–485
2022
-
[39]
IP Info Team. 2017. IP Info
2017
-
[40]
Xingang Shi, Yang Xiang, Zhiliang Wang, Xia Yin, and Jianping Wu. 2012. De- tecting prefix hijackings in the internet with argus. In Proceedings of the 2012 Internet Measurement Conference. 15–28
2012
-
[41]
Zheng Zhang, Ying Zhang, Y Charlie Hu, Z Morley Mao, and Randy Bush. 2008. iSPY: Detecting IP prefix hijacking on my own. In ACM SIGCOMM. 327–338. 12 A Ethics This research study was reviewed and approved by our Institutional Review Board (IRB). All packet-trace data come from...
2008
-
[42]
Dan York. 2014. BGP Hijacking In Iceland And Belarus Shows Increased Need for BGP Security. https://www.internetsociety.org/blog/2014/02/bgp-hijacking- in-iceland-and-belarus-shows-increased-need-for-bgp-security/
2014
-
[2017]
In ACM SIGCOMM
Swift: Predictive fast reroute. In ACM SIGCOMM. 460–473
Reviewed August 6, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.