December 2020 - NANOG - lists.nanog.org

"Hacking" these days - purpose?
by Peter E. Fry 17 Dec '20

17 Dec '20

Simple question: What's the purpose of obtaining illicit access to random devices on the Internet these days, considering that a large majority of attacks are now launched from cheap, readily available and poorly managed/overseen "cloud" services? Finding anything worthwhile to steal on random machines on the Internet seems unlikely, as does obtaining access superior (in e.g. location, bandwidth, anonymity, etc.) to the service from which the attack was launched. I was thinking about this the other day as I was poking at my firewall, and hopped onto the archives (here and elsewhere) to see if I could find any discussion. I found a few mentions (e.g. "Microsoft is hacking my Asterisk???"), but I didn't catch any mention of purpose. Am I missing something obvious (either a purpose or a discussion of such)? Have I lost my mind entirely? (Can't hurt to check, as I'd likely be the last to know.) Peter E. Fry

14 22

Re: "Hacking" these days - purpose?
by Hal Murray 16 Dec '20

16 Dec '20

> Simple question: What's the purpose of obtaining illicit access to random > devices on the Internet these days ... Aside from stealing user's information, there is also stealing industrial and diplomatic secrets. The Chinese stole a lot of F-35 info. The news is full of Russians hacking into US Treasury and Commerce Departments and probably more. -- These are my opinions. I hate spam.

1 0

Fwd: [apnic-talk] APRICOT 2021 call for presentations
by Mark Tinka 16 Dec '20

16 Dec '20

FYI. Mark. -------- Forwarded Message -------- Subject: [apnic-talk] APRICOT 2021 call for presentations Date: Fri, 20 Nov 2020 14:52:26 +1000 From: Philip Smith <pfsinoz(a)gmail.com> Organization: PFS Internet Development Pty Ltd To: apnic-talk(a)lists.apnic.net CC: APRICOT PC Chairs <pc-chairs(a)apricot.net> Hi everyone, As I mentioned last week when I sent out the Call for Volunteers for the APRICOT PC, APRICOT 2021 will be online in February next year. Same dates as we had planned for the in-person meeting. I've included the call for presentations below - looking forward to receiving your presentation proposals! Thanks! philip -- CALL FOR PAPERS =============== The APRICOT 2021 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2021 Conference. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics; Please submit on-line at: http://papers.apricot.net/user/login.php?event=128 Tutorials will take place during the week of 22nd February. Conference sessions and the Peering Forum will take place on the week of 1st March. All APRICOT 2021 sessions times will be one hour long, with up to four sessions scheduled per day. CONFERENCE MILESTONES --------------------- Call for Papers Opens: Now Draft Program Published: As Papers Confirmed Final Deadline for Submissions: 7 February 2021 Final Program Published: 14 February 2021 Final Slides Received: 21 February 2021 *SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF PUBLISHED DEADLINES* PROGRAMME CONTENT ----------------- The APRICOT Conference Programme consists of three parts, these being Tutorials, the Peering Forum, and Conference Sessions. Topics proposed must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and Operations - Internet backbone operations - Peering, Interconnects and IXPs - Network Function Virtualisaton - Network Automation/Programming - Content Distribution Network technology & operations - Research on Internet Operations and Deployment - Network infrastructure security - IPv6 deployment on fixed and Wireless/Cellular networks - DNS / DNSSEC - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing - Content & Service Delivery and "Cloud Computing" PEERING FORUM ------------- Due to APRICOT 2021 being held online, the PC will only accept Peering Personals prior to the event starting. Submissions must be of a single slide listing the operator's PeeringDB entry. Please refer to https://tinyurl.com/y46954n5 for how to create a successful Peering Personal presentation. CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the submission will be rejected immediately. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Slides must be of original work, with all company confidential marks removed. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available programme slots before the deadline. Presenters should endeavour to get material into the PC sooner rather than later. Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Marijana Novakovic & Philip Smith Co-Chairs, APRICOT 2021 Programme Committee -- _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net https://mailman.apnic.net/mailman/listinfo/apnic-talk .

1 0

Re: how many bits of entropy do we need for load balancing?
by Lawrence Wobker 15 Dec '20

15 Dec '20

So I’d argue that the pedantic answer is “you need only as many bits of entropy as your largest fan out” — meaning that 10 bits would allow 1024-way ECMP. But I don’t think that’s what you were actually after... Most of the challenges I’ve seen are not around how many bits you end up with, but rather how you get to those bits. There are lots of different ways to compute the hash values, but if you want to be “fast” you’re unlikely to also get “good” and “cheap”.... generally to select a path, we run a hash function against some set of packet fields, then map that hash to one of the member links. A “perfect” balancing algorithm would be crypto grade hash generation with a large output, and a true modulo operation to select which member we use. The reality is that both crypto hash functions and modulo operations are more expensive than lots of other ways to compute it, so vendors (disclaimer, I work for Cisco) have lots and lots of combinations for how it’s actually done. And then you still have the flow issue: since the vast majority of implementation are hashing flows regardless of their actual bandwidth, if you hash even a few ‘elephants’ onto the same link, you’re not going to get good distribution no matter how good your hashing/selection mechanism is. With respect to your comment about standardization, I doubt you’ll ever be able to get a broad consensus on the combination of “how many bits we need given the others constraints for a spec” and “how much we want to assume about the goodness of the hash generator” and “how much I’m willing to just throw bits at the problem” ... —lj —lj ________________________________ From: Lawrence Wobker <ljwobker(a)gmail.com> Sent: Monday, December 14, 2020 12:33:07 PM To: Pascal Thubert (pthubert) <pthubert(a)cisco.com>; NANOG <nanog(a)nanog.org> Subject: Re: how many bits of entropy do we need for load balancing? So I’d argue that the pedantic answer is “you need only as many bits of entropy as your largest fan out” — meaning that 10 bits would allow 1024-way ECMP. Most of the challenges I’ve seen are not around how many bits you end up with, but rather how you get to that state. There are lots of different ways to compute the hash values, but if you want to be “fast” you’re unlikely to also get “good” and “cheap”.... generally to select a path, we run a hash function against some set of packet fields, then map that hash to one of the member links. A “perfect” balancing algorithm would be crypto grade hash generation with a large output, and a true modulo operation to select which member we use. The reality is that both crypto hash functions and modulo operations are more expensive than lots of other ways to compute it, so vendors (disclaimer, I work for Cisco) have lots and lots of combinations for how it’s actually done. And then you still have the flow issue: since the vast majority of implementation are hashing flows regardless of their actual bandwidth, if you hash even a few ‘elephants’ onto the same link, you’re not going to get good distribution no matter how good your hashing/selection mechanism is. —lj ________________________________ From: NANOG <nanog-bounces+ljwobker=pobox.com(a)nanog.org> on behalf of Pascal Thubert (pthubert) via NANOG <nanog(a)nanog.org> Sent: Monday, December 14, 2020 9:44:05 AM To: NANOG <nanog(a)nanog.org> Subject: how many bits of entropy do we need for load balancing? Dear all: How many bits of entropy do we need for (ECMP) load balancing in the core? This question has kept coming up regularly in many discussions and drafts at the IETF. The IPv6 flow label is 20 bits but hardware implementations do their balancing only on a subset of that, e.g. 12 or 16 bits. There are drafts for MPLS, BIER etc.. that provide their own entropy bit fields of various sizes. I traced to a 6MAN discussion at IETF 78 a claim that 10 or 11 bits were enough. Did someone do the actual exercise? It would be neat to align the IETF specs in the making to whatever truth may be established in the core. Keep safe, Pascal

5 5

how many bits of entropy do we need for load balancing?
by Pascal Thubert (pthubert) 14 Dec '20

14 Dec '20

Dear all: How many bits of entropy do we need for (ECMP) load balancing in the core? This question has kept coming up regularly in many discussions and drafts at the IETF. The IPv6 flow label is 20 bits but hardware implementations do their balancing only on a subset of that, e.g. 12 or 16 bits. There are drafts for MPLS, BIER etc.. that provide their own entropy bit fields of various sizes. I traced to a 6MAN discussion at IETF 78 a claim that 10 or 11 bits were enough. Did someone do the actual exercise? It would be neat to align the IETF specs in the making to whatever truth may be established in the core. Keep safe, Pascal

2 1

Spectrum / TimeWarner contact
by Jared Geiger 14 Dec '20

14 Dec '20

I think Spectrum / Timewarner AS 7843 is dampening one of my routes 199.19.120.0/22. Can someone contact me to help diagnose the issue? We're not a customer traffic leaving Timewarner doesn't make it off the network and I'm unable to trace into the timewarner network. To TW mtr --report 209.18.47.61 HOST: opensips-dsw01.rtc.vocaltra Loss% Snt Last Avg Best Wrst StDev 1. rtr.rtc.vocaltransit.net 0.0% 10 0.2 0.2 0.2 0.3 0.0 2. 216.193.212.89 0.0% 10 0.6 2.4 0.6 8.3 2.8 3. ae12.cr1-was1.ip4.gtt.net 0.0% 10 1.0 1.2 0.9 1.7 0.3 4. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 >From TW mtr --report 199.19.120.1 Start: Mon Dec 14 17:24:57 2020 HOST: rtr-sunvalley Loss% Snt Last Avg Best Wrst StDev 1.|-- 142.254.236.5 0.0% 10 10.0 8.8 7.7 10.0 0.5 2.|-- agg56.vnnzca2402h.socal.r 0.0% 10 13.2 10.4 9.6 13.2 1.0 3.|-- 72.129.14.86 0.0% 10 15.9 14.1 10.3 17.7 2.2 4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0

1 1

Changing DNS host records
by Matthew Crocker 11 Dec '20

11 Dec '20

Hello It has been over a decade since I’ve done this and need some help refreshing my memory. I have many customers that have registered their domains against my authoritative servers (DNS-AUTH3.CROCKER.COM) I need to move that machine to a different network/IP address. I’ve made the updates in my domain (crocker.com) but I think I also need to update the host glue records in the gtld-servers as well. How do I go about doing that? Ultimately the customers need to update their registration with our new authoritative servers, many have but we still have some stragglers I don’t want to break when I shutdown the old servers. Thanks -Matt

5 4

The Real AI Threat?
by Miles Fidelman 11 Dec '20

11 Dec '20

Hi Folks, It occurs to me that network & systems admins are the the folks who really have to worry about AI threats. After watching yet another AI takes over the world show - you know, the same general theme, AI wipes out humans to preserve its existence - it occurred to me: Perhaps the real AI threat is "self-healing systems" gone wild. Consider: - automated system management - automated load management - automated resource management - spin up more instances of <whatever> as necessary - automated threat detection & response - automated vulnerability analysis & response Put them together, and the nightmare scenario is: - machine learning algorithm detects need for more resources - machine learning algorithm makes use of vulnerability analysis library to find other systems with resources to spare, and starts attaching those resources - unbounded demand for more resources Kind of what spambots have done to the global email system. "For Homo Sapiens, the telephone bell had tolled." (Dial F for Frankenstein, Arthur C. Clarke) I think I need to start putting whisky in my morning coffee. And maybe not thinking about NOT replacing third shift with AI tools. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown

12 22

Weekly Routing Table Report
by cscora＠apnic.net 11 Dec '20

11 Dec '20

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 12 Dec, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 833024 Prefixes after maximum aggregation (per Origin AS): 319019 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 399101 Total ASes present in the Internet Routing Table: 70094 Prefixes per ASN: 11.88 Origin-only ASes present in the Internet Routing Table: 60270 Origin ASes announcing only one prefix: 24923 Transit ASes present in the Internet Routing Table: 9824 Transit-only ASes present in the Internet Routing Table: 286 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 36 Prefixes from unregistered ASNs in the Routing Table: 1079 Number of instances of unregistered ASNs: 1080 Number of 32-bit ASNs allocated by the RIRs: 34384 Number of 32-bit ASNs visible in the Routing Table: 28526 Prefixes from 32-bit ASNs in the Routing Table: 130841 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 531 Number of addresses announced to Internet: 2864277120 Equivalent to 170 /8s, 185 /16s and 102 /24s Percentage of available address space announced: 77.4 Percentage of allocated address space announced: 77.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 283782 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 217228 Total APNIC prefixes after maximum aggregation: 64069 APNIC Deaggregation factor: 3.39 Prefixes being announced from the APNIC address blocks: 213269 Unique aggregates announced from the APNIC address blocks: 87397 APNIC Region origin ASes present in the Internet Routing Table: 11101 APNIC Prefixes per ASN: 19.21 APNIC Region origin ASes announcing only one prefix: 3153 APNIC Region transit ASes present in the Internet Routing Table: 1603 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 6224 Number of APNIC addresses announced to Internet: 778323968 Equivalent to 46 /8s, 100 /16s and 72 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-143673 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 240688 Total ARIN prefixes after maximum aggregation: 111288 ARIN Deaggregation factor: 2.16 Prefixes being announced from the ARIN address blocks: 240949 Unique aggregates announced from the ARIN address blocks: 115360 ARIN Region origin ASes present in the Internet Routing Table: 18690 ARIN Prefixes per ASN: 12.89 ARIN Region origin ASes announcing only one prefix: 6809 ARIN Region transit ASes present in the Internet Routing Table: 1913 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3604 Number of ARIN addresses announced to Internet: 1093117952 Equivalent to 65 /8s, 39 /16s and 168 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-401308 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 237159 Total RIPE prefixes after maximum aggregation: 111900 RIPE Deaggregation factor: 2.12 Prefixes being announced from the RIPE address blocks: 233076 Unique aggregates announced from the RIPE address blocks: 137705 RIPE Region origin ASes present in the Internet Routing Table: 27564 RIPE Prefixes per ASN: 8.46 RIPE Region origin ASes announcing only one prefix: 11851 RIPE Region transit ASes present in the Internet Routing Table: 3893 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9735 Number of RIPE addresses announced to Internet: 709722752 Equivalent to 42 /8s, 77 /16s and 130 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-213403 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 112113 Total LACNIC prefixes after maximum aggregation: 26185 LACNIC Deaggregation factor: 4.28 Prefixes being announced from the LACNIC address blocks: 113225 Unique aggregates announced from the LACNIC address blocks: 47917 LACNIC Region origin ASes present in the Internet Routing Table: 10626 LACNIC Prefixes per ASN: 10.66 LACNIC Region origin ASes announcing only one prefix: 2626 LACNIC Region transit ASes present in the Internet Routing Table: 1967 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 33 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8216 Number of LACNIC addresses announced to Internet: 174113024 Equivalent to 10 /8s, 96 /16s and 193 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 24755 Total AfriNIC prefixes after maximum aggregation: 4791 AfriNIC Deaggregation factor: 5.17 Prefixes being announced from the AfriNIC address blocks: 31974 Unique aggregates announced from the AfriNIC address blocks: 10289 AfriNIC Region origin ASes present in the Internet Routing Table: 1420 AfriNIC Prefixes per ASN: 22.52 AfriNIC Region origin ASes announcing only one prefix: 483 AfriNIC Region transit ASes present in the Internet Routing Table: 287 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 747 Number of AfriNIC addresses announced to Internet: 108557312 Equivalent to 6 /8s, 120 /16s and 116 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 5676 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3577 1330 21 VIETEL-AS-AP Viettel Group, VN 7713 3227 952 519 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 2842 1896 55 VNPT-AS-VN VNPT Corp, VN 9808 2574 9044 57 CMNET-GD Guangdong Mobile Communication 4766 2356 11104 565 KIXS-AS-KR Korea Telecom, KR 9498 2297 466 232 BBIL-AP BHARTI Airtel Ltd., IN 4755 2133 441 189 TATACOMM-AS TATA Communications formerl 45090 2064 1045 63 CNNIC-TENCENT-NET-AP Shenzhen Tencent C Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 4755 315 695 CABLEONE, US 16509 4501 9066 2085 AMAZON-02, US 7155 4019 264 32 VIASAT-SP-BACKBONE, US 22773 3739 2994 196 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3357 1319 83 SHAW, CA 16625 3124 1641 2247 AKAMAI-AS, US 209 2525 5059 511 CENTURYLINK-US-LEGACY-QWEST, US 30036 2487 370 113 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2336 2984 1643 FRONTIER-FRTR, US 20115 2165 2899 504 CHARTER-20115, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 47331 6502 900 3642 TTNET, TR 12479 6226 1667 141 UNI2-AS, ES 39891 3459 195 22 ALJAWWALSTC-AS, SA 20940 3330 3347 200 AKAMAI-ASN1, EU 8551 3237 379 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2881 2282 892 ROSTELECOM-AS, RU 9009 2235 231 1219 M247, GB 34984 2167 351 576 TELLCOM-AS, TR 13188 1610 100 31 TRIOLAN, UA 58224 1449 853 541 TCI, IR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 8187 3442 603 Uninet S.A. de C.V., MX 10620 3396 526 550 Telmex Colombia S.A., CO 11830 2565 369 63 Instituto Costarricense de Electricidad 13999 1561 430 411 Mega Cable, S.A. de C.V., MX 6503 1444 311 475 Axtel, S.A.B. de C.V., MX 7303 1435 909 262 Telecom Argentina S.A., AR 28573 1371 2259 223 CLARO S.A., BR 6147 1147 379 39 Telefonica del Peru S.A.A., PE 3816 1113 537 151 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 999 212 418 Techtel LMDS Comunicaciones Interactiva Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1567 393 22 LINKdotNET-AS, EG 24835 1288 480 25 RAYA-AS, EG 36992 1206 1529 133 ETISALAT-MISR, EG 36903 950 496 96 MT-MPLS, MA 29571 709 68 12 ORANGE-COTE-IVOIRE, CI 6713 533 1863 34 IAM-AS, MA 15399 485 46 17 WANANCHI-, KE 37342 478 32 1 MOVITEL, MZ 36935 464 522 40 Vodafone-, EG 23889 450 232 16 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 8187 3442 603 Uninet S.A. de C.V., MX 47331 6502 900 3642 TTNET, TR 12479 6226 1667 141 UNI2-AS, ES 7545 5676 777 661 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4192 73 ERX-CERNET-BKB China Education and Rese 11492 4755 315 695 CABLEONE, US 16509 4501 9066 2085 AMAZON-02, US 7155 4019 264 32 VIASAT-SP-BACKBONE, US 22773 3739 2994 196 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3577 1330 21 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 6226 6085 UNI2-AS, ES 7545 5676 5015 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4755 4682 ERX-CERNET-BKB China Education and Research Net 11492 4755 4060 CABLEONE, US 7155 4019 3987 VIASAT-SP-BACKBONE, US 7552 3577 3556 VIETEL-AS-AP Viettel Group, VN 22773 3739 3543 ASN-CXA-ALL-CCI-22773-RDC, US 39891 3459 3437 ALJAWWALSTC-AS, SA 6327 3357 3274 SHAW, CA 8551 3237 3194 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 18604 UNALLOCATED 8.25.204.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 46766 UNALLOCATED 8.44.208.0/24 3356 LEVEL3, US 40544 UNALLOCATED 12.0.33.0/24 6461 ZAYO-6461, US 393489 UNALLOCATED 12.7.109.0/24 7018 ATT-INTERNET4, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.141.0.0/24 Origin: 395350 UNASSIGNED Transit: 11426 TWC-11426-CAROLINAS, US 23.142.80.0/24 Origin: 397294 UNASSIGNED Transit: 398559 TUNBROKER, US 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad No. 14, Jala 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad No. 14, Jala Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:8 /9:13 /10:40 /11:101 /12:292 /13:579 /14:1175 /15:1932 /16:13469 /17:8249 /18:13675 /19:25588 /20:41340 /21:50275 /22:103262 /23:87738 /24:484046 /25:1242 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 47331 5724 6502 TTNET, TR 12479 5201 6226 UNI2-AS, ES 11492 3803 4755 CABLEONE, US 6327 3152 3357 SHAW, CA 7155 3108 4019 VIASAT-SP-BACKBONE, US 8151 2892 8187 Uninet S.A. de C.V., MX 22773 2867 3739 ASN-CXA-ALL-CCI-22773-RDC, US 39891 2801 3459 ALJAWWALSTC-AS, SA 8551 2699 3237 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 2225 2487 MEDIACOM-ENTERPRISE-BUSINESS, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1879 2:1143 3:35 4:18 5:3408 6:53 8:1484 9:1 11:1 12:1759 13:351 14:2397 15:72 16:13 17:302 18:93 20:111 23:4139 24:2359 25:3 27:2340 31:2162 32:112 34:1 35:35 36:1128 37:3507 38:2000 39:476 40:150 41:3866 42:616 43:2111 44:236 45:14651 46:3618 47:322 49:1607 50:1680 51:90 52:1129 54:213 55:781 56:6 57:56 58:1691 59:1144 60:817 61:2305 62:2197 63:2016 64:5226 65:2380 66:5121 67:2951 68:1170 69:4101 70:1400 71:685 72:3090 74:2545 75:1457 76:687 77:1973 78:3178 79:2493 80:1917 81:1630 82:1297 83:1105 84:1251 85:3100 86:619 87:1784 88:2428 89:2868 90:402 91:7167 92:1590 93:2549 94:2910 95:4162 96:1228 97:341 98:968 99:976 100:90 101:1048 102:1211 103:24992 104:3616 105:390 106:775 107:2172 108:686 109:3743 110:2001 111:2346 112:1652 113:1533 114:1415 115:1853 116:1862 117:2118 118:2276 119:1863 120:939 121:1040 122:2295 123:2126 124:1631 125:2133 128:1384 129:1258 130:770 131:1996 132:746 133:311 134:1390 135:331 136:684 137:899 138:2293 139:1157 140:737 141:1161 142:1041 143:1249 144:1210 145:334 146:1361 147:1212 148:2170 149:1262 150:758 151:1201 152:1603 153:446 154:2298 155:1261 156:1353 157:1133 158:912 159:2040 160:2039 161:1078 162:3202 163:920 164:1422 165:1314 166:600 167:1719 168:3627 169:630 170:4359 171:743 172:2007 173:2923 174:966 175:1060 176:2910 177:4440 178:2785 179:1896 180:2280 181:2578 182:3160 183:1516 184:2403 185:17553 186:4025 187:3053 188:3298 189:2728 190:9091 191:1400 192:10585 193:7846 194:6379 195:4581 196:3109 197:2297 198:6010 199:5940 200:7310 201:5269 202:10566 203:10142 204:4633 205:3096 206:3295 207:3311 208:3986 209:4608 210:4193 211:2095 212:3587 213:3193 214:1189 215:61 216:6143 217:2472 218:897 219:637 220:2086 221:929 222:975 223:1701 End of report

1 0

Questions for Level3 & Choopa about their Enabling of IP Hijacking (RPKI Invalid)
by lists＠geeksolutions.ca 11 Dec '20

11 Dec '20

Is there anyone on this list at Level3 or Choopa who can respond to why: 1. Level3/Centurylink/Lumen: How come RPKI invalid prefixes were allowed to be announced and considered valid? 2. Level3/Centurylink/Lumen: Is there any actual NOC hidden behind the numbers where someone can reasonably be of assistance? Why are your SOC, Support and DDoS team saying you can't blackhole a hijacked prefix because of "GOVERNMENT regulations"? 3. CHOOPA: Why does your Vultr brand allow anyone who can successfully insert an IRR record (eg, in RaDB) to be imported (even when RPKI is invalid) and permit hijacking? 4. CHOOPA: Why does your Network Team need 3 days to check an RPKI valid or invalid? It is not rocket science. Please feel free to contact me off the list with these answers. If you are interested in the long story of the whole ordeal of being hijacked for 3 days, it is below. IP hijacking ordeal we went through: We are extremely disappointed with Choopa/Vultr and Level3. On 2020-12-07 at exactly 23:48:10, we notified Choopa and Vultr via email, ticket and contact form that one of our IPv4 prefixes was being hijacked by one of their customers. Our prefixes are RPKI signed, and the ASN announcing the prefix was not in the RPKI sign. We continued to follow up on the request, and sent more requests in to Vultr/Choopa's system. When we phoned Choopa, we were told by the individual on the phone that they see the ticket, and they'll bump it up on the network engineering ticket list. Frustrated after three days of an ongoing hijack, and consistently no assistance from Vultr or it's parent Choopa, we reached out to the only Tier-1 Choopa has in London that was NOT filtering according to RPKI, Level3. We sent an email to the noc(a)level3carrier.com, which was listed as a point of contact on the ASN & PeeringDB pages. The email had no response. We then called the number (1-833-453-8353), and spoke to Technical Support, who transferred us the first time to the SOC, the second time to their DDoS department. The person who responded in the SOC said that they can filter it "very fast" if we validate ownership of the prefix (despite being RPKI signed). So we complied, we were told to email "abuse(a)centurylinkservices.net" with a message saying the prefix is being hijacked, the ASN of the hijacker and the direct upstream (Vultr/Choopa). We sent that email, he said we "should get" an automatic reply (none arrived, confirmed with mx it was delivered). We waited half an hour, which they agreed was a "reasonable time" to wait for it to be filtered. After half an hour, we followed up, and this time landed on the DDoS department (I have no clue how they thought this through). At the DDoS department, they said that they can't help, and I should "keep emailing" abuse(a)centurylinkservices.net. He offered a phone number for me to call as a "direct line to abuse", upon hanging up and dialing, I got to the generic prompts for *customer services*. They were no help either. Fast forward four hours, we have no point of contact at Level3 or Choopa, we have had no communication from either. We finally get a message from Choopa, reading: "Greetings, This ticket has been forwarded to our networking team so they can examine your situation, check the infrastructure configuration, and apply any relevant changes. Please allow for significant additional time while we review this ticket." "Significant additional time" to check an RPKI valid? That seems incredibly odd. Fast forward to another hour, we receive the next of Choopa messages, this time saying: "Thanks for the update on this. We have validated the removal request and have removed the prefix from our network. Please allow additional time for this to update to the providers.". We finally thought we were in the clear. Almost two hours go by, and the prefix is still not filtered what-so-ever. We follow up once more, and are told "We have removed the prefix and is not announced by Vultr anymore. Please allow 24 to 48 hours for the internet providers to update their routing database." Finally, an hour later, nlnog & other lg's are seeing Level3 no longer announcing the prefix. What we found out in the process is Vultr ignores RPKI invalid (despite having a table on their system which shows RPKI Invalid/Invalid ASN), as long as at one point in time an IRR record existed (or, is created). Once Vultr gets their hands on it, they make the IRR records at RaDB, and keep updating them even when they're not valid. With the run around of Level3, and Choopa/Vultr, they're practically inviting IP hijackers to play. Insanity!

1 0