Pith. sign in

REVIEW 3 major objections 6 minor 28 references

Grey Rhino Warning: IPv6 is Becoming Fertile Ground for Reflection Amplification Attacks

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that current IPv6 networks are fertile ground for reflection amplification: 61.36% of measured autonomous systems lack inbound source address validation, and verified DNS, NTP, and SNMP amplifiers in 3,507 ASes reach a…

desk verdict A useful IPv6 amplifier census with a real methodological contribution, but the headline ISAV numbers carry unquantified false-positive risk and need error analysis before the exact figures are taken at face value. read the letter →

arxiv 2506.04768 v1 pith:27IXSGDR submitted 2025-06-05 cs.NI

Ling Hu , Tao Yang , Yu Pang , Bingnan Hou , Zhiping Cai , Bo Yu This is my paper
classification cs.NI
keywords IPv6securityreflectionamplificationattacksinboundsourceaddressvalidationDDoSICMPTimeExceededprobingfactoractivescanningDNSNTPSNMP
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper attempts to establish that the IPv6 internet is currently a fertile ground for reflection amplification attacks, the "grey rhino" of the title. It reports that 4,460 of 7,269 measured autonomous systems (61.36%) do not implement inbound source address validation (ISAV), meaning spoofed packets can enter them, and that probing roughly 47 million active addresses inside those networks found verified amplifiers in 3,507 ASes across DNS, NTP, and SNMP, with bandwidth amplification factors up to 4,267. The result matters because DDoS defense has historically focused on IPv4; if IPv6 ISAV deployment stays this low, the enormous IPv6 address space gives attackers a fresh, under-scrutinized pool of reflectors. A sympathetic reader would take this as a measured warning that ISAV adoption must be treated as an IPv6 security priority, not an IPv4 legacy issue.

What carries the argument

The load-bearing mechanism is a spoofed-source ICMP Time Exceeded probe combined with traceroute cross-validation. The vantage point sends packets with carefully chosen TTLs so that routers along the path generate ICMP Time Exceeded replies; by spoofing the source address as that of the target, a reply reaching the target proves the router accepted a packet that appeared to come from the target. Only when that router is on the vantage-to-host path but not on the target-to-host path (the paper's Type-2 geometry) does the AS get classified as lacking ISAV, because in that case the packet's source address is not legitimate from the router's topological perspective. A stateless randomized traceroute method collects the probe replies efficiently, active-address collection limits scanning to reachable IPv6 hosts, and reflection tests from the vantage with the target listening verify actual amplification and compute the bandwidth amplification factor BAF.

What would settle it

Take a set of ASes whose ISAV status is known from router configuration data, run the paper's Type-2 test, and count how many known-filtering ASes are classified as vulnerable; if a significant share of filtering ASes are flagged because their routers do not emit ICMP Time Exceeded on the target's path, the inference is unsound.

Watch

Extended reading notes

Core claim

The central discovery is that AS-level vulnerability to reflection amplification in IPv6 is widespread and can be measured at global scale with only two vantage points. The authors send spoofed ICMP probes with incremental TTLs from one vantage point and observe at a second vantage point which routers and hosts reply, inferring which ASes receive packets whose source address is not topologically valid. They keep only Type-2 observations, where the replying router lies on the vantage-to-host path but not on the target-to-host path, because only those prove the AS lacks ISAV. The five-round October 2024 measurement classifies 4,460 ASes as lacking ISAV, and within those ASes scanning about 47 million active addresses and testing DNS, NTP, and SNMP yields 141,006 verified amplifiers in 3,507 ASes. The highest bandwidth amplification factor is 4,267 (NTP), with NTP averaging 665, while DNS averages 32.51, SNMPv2 115.26, and SNMPv3 only 4.46. The paper concludes that current IPv6 networks are fertile ground for reflection amplification attacks.

Load-bearing premise

The ISAV classification rests on the assumption that both traceroutes, from the vantage point and from the target to each scanned host, are complete and accurate, so a router that silently drops ICMP Time Exceeded packets cannot make an ISAV-deploying AS look vulnerable.

Editorial extensions

If this is right

  • An attacker with a spoofing-capable source AS can direct amplified UDP floods at any victim inside one of the 4,460 vulnerable ASes, since ISAV is exactly what would stop the spoofed packets at the border.
  • NTP is the highest-risk protocol measured: it appears across 1,555 ASes, yields an average amplification of 665x and a maximum of 4,267x, so NTP monlist abuse should be a first target for patching and response-rate limiting.
  • AS-level triage works: scanning only about 47 million active addresses inside vulnerable ASes exposed 141,006 verified amplifiers, so defenders can prioritize ISAV deployment without enumerating the whole IPv6 address space.
  • IPv6 amplifier inventories churn quickly, since only 4.71% of scanned addresses remained reachable after a week, meaning continuous re-scanning is needed and static address blacklists will decay almost immediately.
  • Combining ISAV with outbound source address validation on the attacker side would suppress most of the risk, because the attack chain depends on source-address spoofing at both ends.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension would be to run the same spoofed-probe logic in reverse to map outbound source address validation gaps, giving a single global graph of which ASes can both send spoofed traffic and accept it.
  • Using more than two vantage points would shrink the 17.18% of ASes left "uncertain" by the Type-1/Type-2 test and could detect ISAV deployment behind the first filtering AS, yielding a more complete vulnerability map.
  • The 4,267x NTP amplification, if it holds up under replication, exceeds typical IPv4 NTP figures, so a direct IPv4-versus-IPv6 comparison of monlist exposure on the same servers would be a straightforward next test.
  • Because AS-level vulnerability persists even as individual IPv6 addresses turn over, operational defenses should favor prefix- and AS-level filtering and rate limits over host-level blocklists.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. This paper proposes a two-vantage-point measurement methodology to infer, at AS level, which IPv6 networks lack inbound source address validation (ISAV). The first vantage point runs traceroute to randomly generated IPv6 addresses in BGP prefixes and also sends the same probes with the source address spoofed as the second vantage point; ICMP Time Exceeded messages received at the target identify routers that accept spoofed packets. Comparing the target's own traceroute to the same hosts, routers on the spoofed path but not on the target path are interpreted as Type 2 evidence that their AS lacks ISAV. The authors then scan active addresses in the classified vulnerable ASes, probe DNS, NTP, and SNMP services, and verify reflected amplification using the spoofing vantage and the passive listener. They report that 4,460 of 7,269 measured ASes (61.36%) lack ISAV, that 3,507 ASes contain verified amplifiers, and that the maximum bandwidth amplification factor observed is 4,267x for NTP.

Significance. If the measurements are sound, this is a timely and valuable first global picture of IPv6 ISAV deployment and amplifier exposure, directly relevant to DDoS defense and IPv6 deployment decisions. Strengths include the use of direct observations rather than fitted models, the explicit AS-level framing, the qualitative consistency with earlier ISAV studies, and the public code release. However, the headline ISAV and amplifier counts rest on unvalidated router-level assumptions and underspecified measurement protocols. Until those are addressed, the exact numbers should be read as an upper-bound estimate rather than a confirmed statistic; the qualitative conclusion that IPv6 contains substantial reflection-amplification risk remains plausible.

major comments (3)
  1. [Section III-B, Algorithm 1] The Type 2 test in Algorithm 1 (Lines 9–13) treats a router in Group_spoof that is absent from Group_target as proof that the router's AS lacks ISAV. This is valid only if Group_target contains every router on every path from T to H. Incomplete target-side traceroutes due to ICMP Time Exceeded suppression, and ECMP/load-balanced forwarding, mean that a shared router can be missing from Group_target, so an AS that does deploy ISAV can be classified as vulnerable. The Limitations section acknowledges that routers may not return ICMP Time Exceeded, but it frames this only as a source of missed detections; it is also a source of false positives for the headline figure of 4,460 ASes (61.36%) in Section IV-B. I ask for a quantitative false-positive analysis, for example repeated or Paris traceroutes from the target, validation against ASes with known ISAV status, or a sensitivity analysis that varies the completeness assumption.
  2. [Section III-C and Table I] The amplifier verification step is not specified at a reproducible level. The text states that the vantage sends spoofed service requests and the target listens, but it never defines how an amplifier is distinguished from an open server, what query types and rates were used for DNS, NTP, and SNMP, what counts as a successful exploitation, or how the three protocols were mapped to the roughly 47M scanned addresses. Since the claim that 3,507 ASes contain amplifiers (Section IV-B) depends on this step, the methodology must be precise enough to rule out artifacts such as responses generated by middleboxes or responses that never actually reach the target.
  3. [Section IV-A] The data-collection description is too sparse to reproduce or assess error. There is no statement of how many target addresses were generated per prefix or AS, how the three Yarrp runs in Algorithm 1 were synchronized, how ICMP rate limiting at either vantage was handled, how the 47M active addresses were selected, or what packet sizes and rates were used in the service scans. These parameters can change both the ISAV classification and the amplifier counts, so their absence makes the numerical results difficult to interpret as precise measurements.
minor comments (6)
  1. [Figure 2] The rendered heatmap contains raw Unicode escape fragments such as '/uni00000018/uni00000013' instead of readable country labels; the figure needs to be regenerated.
  2. [Equations (1) and (2)] The paper introduces AF as a product of the number of amplifiers, PAF, SAF, and TCF, but all reported results use BAF and ignore TCF and the number of amplifiers; please clarify the relationship and justify the simplification.
  3. [Section IV-A] The text says that five rounds of scanning were conducted but reports only aggregate numbers; per-round counts and variability would help assess the stability of the ISAV measurement.
  4. [Section III-A] The notation 'ISA V' appears with a spurious space throughout the text; this should be corrected to 'ISAV'.
  5. [Section II-C] The claim that the vantage points are 'capable only of sending spoofed packets (without monitoring or modifying traffic)' is inconsistent with Algorithm 1 Line 5, where the target vantage sends its own traceroute; please reconcile the description.
  6. [Section V, Limitations] The discussion of incomplete ICMP replies should also mention ECMP and multipath effects on the target-side traceroute, not only suppression of ICMP Time Exceeded messages by routers.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: ISAV inference, amplifier discovery, and BAF measurement are independent observational steps; no fitted parameter is renamed as a prediction.

full rationale

The derivation chain is observational rather than definitional. The paper infers AS-level ISAV deployment with Algorithm 1 by checking whether a spoofed-traceroute router is absent from the target's traceroute (Type 2), then independently scans active IPv6 addresses and verifies DNS/NTP/SNMP reflection with spoofed queries to a controlled target. The 61.36% figure is a classification outcome, not an input: it is not assumed by definition, and it is cross-checked against independent prior ISAV studies (68.6%, 69.8%, 67.37%). Amplifier counts and BAF values (e.g., NTP 4,267x) are direct measurements of observed packets, not outputs of a model fitted to the conclusion. The self-citations [23], [24] supply IPv6 active-address/hitlist generation tools; they are not load-bearing for the ISAV or amplifier claims, and the paper is self-contained against external benchmarks. The Limitations section (Sec. V) does acknowledge that 'not all routers reliably return ICMP timeout messages'; as the skeptic notes, this can also create false positives in the Type 2 test if a router is absent from a target-side traceroute but still lies on T's path. That is a measurement-validity threat warranting error bounds or ground truth, but it is not circularity, because the ISAV classification and the amplifier/BAF measurements are independent observations and no reported quantity is equivalent by construction to a fitted input.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The central claim relies on five measurement assumptions, mostly about ICMP behavior and path completeness. There are no invented entities and no fitted model parameters; the only hand-set value is the initial TTL. The paper does not derive a quantitative relationship from first principles.

free parameters (1)
  • Initial TTL for ISAV detection probes = 4
    Chosen to avoid triggering frequent ICMP reports from routers near the vantage point; this setting determines which on-path routers are observed and therefore which ASes can be classified as vulnerable (Section IV-A).
assumptions (5)
  • domain assumption Routers that receive spoofed IPv6 packets with expiring TTL send ICMP Time Exceeded to the spoofed source address.
    Invoked in Section III-A to infer reception from ICMP messages; the paper admits in Limitations that many routers do not return ICMP, so this assumption can only undercount, not overcount, router responses.
  • domain assumption Traceroute from the target and vantage reveals all relevant on-path routers.
    Algorithm 1 Lines 3-5 and Section III-B rely on complete path information to distinguish Type 1 from Type 2; incomplete target paths can create false Type 2 classifications.
  • domain assumption If one router in an AS accepts a spoofed packet, the whole AS lacks ISAV.
    Section III-B Type 2 and Algorithm 1 Lines 11-13 use a single router's response to mark the AS vulnerable; this is valid for vulnerability assessment but may overstate the absence of ISAV on other ingress paths.
  • domain assumption The controlled vantage points can source-spoof packets.
    Section II-C assumes spoofing capability is available and cites CAIDA estimates on global spoofing frequency, but does not demonstrate that the two specific networks permit it.
  • domain assumption Open DNS, NTP, and SNMP service responses observed in a reflection test imply usable amplifiers.
    Section III-C selection of protocols follows prior work [1] and the tests verify that a spoofed query produces a response at the target; this is a lower bound because only a few query types were tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Grey Rhino Warning: IPv6 is Becoming Fertile Ground for Reflection Amplification Attacks." pith.science (2026). https://pith.science/paper/27IXSGDR

@misc{pith2026250604768,
  author       = {Pith},
  title        = {Pith review of: Grey Rhino Warning: IPv6 is Becoming Fertile Ground for Reflection Amplification Attacks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/27IXSGDR}},
  note         = {Machine review of arXiv:2506.04768}
}
read the original abstract

Distributed Denial-of-Service (DDoS) attacks represent a cost-effective and potent threat to network stability. While extensively studied in IPv4 networks, DDoS implications in IPv6 remain underexplored. The vast IPv6 address space renders brute-force scanning and amplifier testing for all active addresses impractical. Innovatively, this work investigates AS-level vulnerabilities to reflection amplification attacks in IPv6. One prerequisite for amplification presence is that it is located in a vulnerable autonomous system (AS) without inbound source address validation (ISAV) deployment. Hence, the analysis focuses on two critical aspects: global detection of ISAV deployment and identification of amplifiers within vulnerable ASes. Specifically, we develop a methodology combining ICMP Time Exceeded mechanisms for ISAV detection, employ IPv6 address scanning for amplifier identification, and utilize dual vantage points for amplification verification. Experimental results reveal that 4,460 ASes (61.36% of measured networks) lack ISAV deployment. Through scanning approximately 47M active addresses, we have identified reflection amplifiers in 3,507 ASes. The analysis demonstrates that current IPv6 networks are fertile grounds for reflection amplification attacks, alarming network security.

Figures

Figures reproduced from arXiv: 2506.04768 by the authors.

Figure 1
Figure 1. Three types of positional relationships among AS [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Heatmap of the distribution of vulnerable ASes around the world. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    Amplification hell: Revisiting network protocols for ddos abuse

    C. Rossow, “Amplification hell: Revisiting network protocols for ddos abuse.” inIn the proceeding of the 30th USENIX Security Symposium (USENIX Security 14), 2014, pp. 1–15

    work page 2014

  2. [2]

    February 28th ddos incident report,

    S. Kottler, “February 28th ddos incident report,” 2018. [Online]. Available: https://github.blog/2018-03-01-ddos-incident-report/

    work page 2018

  3. [3]

    How to deal with ddos attacks on a global scale,

    A. C. Security, “How to deal with ddos attacks on a global scale,” 2019. [Online]. Available: https://www.alibabacloud.com/blog/ how-to-deal-with-ddos-attacks-on-a-global-scale 595641

    work page 2019

  4. [4]

    Ipv6 adoption visualization,

    Akamai, “Ipv6 adoption visualization,” 2024. [On- line]. Available: https://www.akamai.com/internet-station/cyber-attacks/ state-of-the-internet-report/ipv6-adoption-visualization

    work page 2024

  5. [5]

    Dnsbomb: A new practical-and- powerful pulsing dos attack exploiting dns queries-and-responses,

    X. Li, D. Wu, H. Duan, and Q. Li, “Dnsbomb: A new practical-and- powerful pulsing dos attack exploiting dns queries-and-responses,” in Proceedings of the 2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2024, pp. 253–253

    work page 2024

  6. [6]

    Tsuking: Coordinating dns resolvers and queries into potent dos amplifiers,

    W. Xu, X. Li, C. Lu, B. Liu, H. Duan, J. Zhang, J. Chen, and T. Wan, “Tsuking: Coordinating dns resolvers and queries into potent dos amplifiers,” inProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 311–325

    work page 2023

  7. [7]

    Tsuname: ex- ploiting misconfiguration and vulnerability to ddos dns,

    G. C. Moura, S. Castro, J. Heidemann, and W. Hardaker, “Tsuname: ex- ploiting misconfiguration and vulnerability to ddos dns,” inProceedings of the 21st ACM Internet Measurement Conference, 2021, pp. 398–418

    work page 2021

  8. [8]

    Behind closed doors: a network tale of spoofing, intrusion, and false dns security,

    C. Deccio, A. Hilton, M. Briggs, T. Avery, and R. Richardson, “Behind closed doors: a network tale of spoofing, intrusion, and false dns security,” inProceedings of the ACM Internet Measurement Conference. ACM, 2020, pp. 65–77

    work page 2020

Show all 28 references
  1. [9]

    Don’t forget to lock the front door! inferring the deployment of source address validation of inbound traffic,

    M. Korczy ´nski, Y . Nosyk, Q. Lone, M. Skwarek, B. Jonglez, and A. Duda, “Don’t forget to lock the front door! inferring the deployment of source address validation of inbound traffic,” inProceedings of the Passive and Active Measurement: 21st International Conference. Spring...

    2020

  2. [10]

    Taming the 800 pound gorilla: The rise and decline of ntp ddos attacks,

    J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bailey, and M. Karir, “Taming the 800 pound gorilla: The rise and decline of ntp ddos attacks,” inProceedings of the 2014 Conference on Internet Measurement Conference, 2014, pp. 435–448

    2014

  3. [11]

    Ip spoofing,

    CAIDA, “Ip spoofing,” 2024. [Online]. Available: https://spoofer.caida. org/summary.php

    2024

  4. [12]

    Network hygiene, incentives, and regulation: deployment of source address validation in the internet,

    M. Luckie, R. Beverly, R. Koga, K. Keys, J. A. Kroll, and K. Claffy, “Network hygiene, incentives, and regulation: deployment of source address validation in the internet,” inProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 465–480

    2019

  5. [13]

    Spoofer project,

    CAIDA, “Spoofer project,” 2022. [Online]. Available: https://www. caida.org/projects/spoofer

    2022

  6. [14]

    Understanding the efficacy of deployed internet source address validation filtering,

    R. Beverly, A. Berger, Y . Hyun, and K. Claffy, “Understanding the efficacy of deployed internet source address validation filtering,” in Proceedings of the 9th ACM SIGCOMM conference on Internet mea- surement, 2009, pp. 356–369

    2009

  7. [15]

    Your Router is My Prober: Measuring IPv6 Networks via ICMP Rate Limiting Side Channels,

    L. Pan, J. Yang, L. He, Z. Wang, L. Nie, G. Song, and Y . Liu, “Your Router is My Prober: Measuring IPv6 Networks via ICMP Rate Limiting Side Channels,” inProceedings of the 30th Annual Network and Distributed System Security Symposium, NDSS 2023, no. March, 2023

    2023

  8. [16]

    Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,

    M. Gupta and A. Conta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” RFC 4443, Mar. 2006. [Online]. Available: https://www.rfc-editor.org/info/rfc4443

    2006

  9. [17]

    Det: Enabling efficient probing of ipv6 active addresses,

    G. Song, J. Yang, Z. Wang, L. He, J. Lin, L. Pan, C. Duan, and X. Quan, “Det: Enabling efficient probing of ipv6 active addresses,”IEEE/ACM Transactions on Networking, vol. 30, no. 4, pp. 1629–1643, 2022

    2022

  10. [18]

    Weaponizing middleboxes for{TCP}reflected amplification,

    K. Bock, A. Alaraj, Y . Fax, K. Hurley, E. Wustrow, and D. Levin, “Weaponizing middleboxes for{TCP}reflected amplification,” inPro- ceedings of the 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 3345–3361

    2021

  11. [19]

    Using loops observed in traceroute to infer the ability to spoof,

    Q. Lone, M. Luckie, M. Korczy ´nski, and M. Van Eeten, “Using loops observed in traceroute to infer the ability to spoof,” inPassive and Active Measurement: 18th International Conference, PAM 2017, Sydney, NSW, Australia, March 30-31, 2017, Proceedings 18. Springer, 2017, pp. 229–241

    2017

  12. [20]

    Challenges in inferring spoofed traffic at ixps,

    L. M ¨uller, M. Luckie, B. Huffaker, K. Claffy, and M. Barcellos, “Challenges in inferring spoofed traffic at ixps,” inProceedings of the 15th International Conference on Emerging Networking Experiments and Technologies, 2019, pp. 96–109

    2019

  13. [21]

    Ip address to autonomous system number lookups,

    H. Asghari and A. Noroozian, “Ip address to autonomous system number lookups,” 2024. [Online]. Available: https://pypi.org/project/pyasn/

    2024

  14. [22]

    Yarrp’ing the internet: Randomized high-speed active topology discovery,

    R. Beverly, “Yarrp’ing the internet: Randomized high-speed active topology discovery,” inProceedings of the 2016 Internet Measurement Conference, 2016, pp. 413–420

    2016

  15. [23]

    Search in the expanse: Towards active and global ipv6 hitlists,

    B. Hou, Z. Cai, K. Wu, T. Yang, and T. Zhou, “Search in the expanse: Towards active and global ipv6 hitlists,” inIEEE INFOCOM 2023-IEEE Conference on Computer Communications. IEEE, 2023, pp. 1–10

    2023

  16. [24]

    6forest: an ensemble learning- based approach to target generation for internet-wide ipv6 scanning,

    T. Yang, Z. Cai, B. Hou, and T. Zhou, “6forest: an ensemble learning- based approach to target generation for internet-wide ipv6 scanning,” in IEEE INFOCOM 2022-IEEE Conference on Computer Communications. IEEE, 2022, pp. 1679–1688

    2022

  17. [25]

    Fast ipv6 network periphery discovery and security implications,

    X. Li, B. Liu, X. Zheng, H. Duan, Q. Li, and Y . Huang, “Fast ipv6 network periphery discovery and security implications,” in2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2021, pp. 88–100

    2021

  18. [26]

    Smap: Internet-wide scanning for spoofing,

    T. Dai and H. Shulman, “Smap: Internet-wide scanning for spoofing,” inProceedings of the 37th Annual Computer Security Applications Conference, 2021, pp. 1039–1050

    2021

  19. [27]

    Geolite2 free geolocation data,

    Maxmind, “Geolite2 free geolocation data,” 2024. [Online]. Available: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data/

    2024

  20. [28]

    Third time’s not a charm: Exploiting SNMPv3 for router fingerprinting,

    T. Albakour, O. Gasser, R. Beverly, and G. Smaragdakis, “Third time’s not a charm: Exploiting SNMPv3 for router fingerprinting,”Proceedings of the ACM Internet Measurement Conference, IMC, pp. 150–164, 2021

    2021

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.