- Test - lists.nanog.org

Fwd: [PDB Announce] Publication of Guidelines for Registering in PeeringDB
by Leo Vegoda 02 Nov '21

02 Nov '21

Hi, There was a recent discussion on this list about registering in PeeringDB, so I am forwarding this announcement about the publication of the guidelines used and the process in place to improve them when needed. Kind regards, Leo ---------- Forwarded message --------- From: Leo Vegoda <leo(a)peeringdb.com> Date: Tue, Nov 2, 2021 at 11:32 AM Subject: [PDB Announce] Publication of Guidelines for Registering in PeeringDB To: <pdb-announce(a)lists.peeringdb.com> Hi, We recently published the guidelines used by PeeringDB's Admin Committee for registering in PeeringDB. The main goals are: - To provide multiple paths - To show the workflows and the exception process - To provide some examples We have a blog post about the publication here: https://docs.peeringdb.com/blog/guidelines_for_registering/ And the guidelines themselves are here: https://docs.peeringdb.com/committee/admin/approval-guidelines/ These guidelines are part of work to document more of what PeeringDB does and how it does it. You might have noticed the HOWTO document we have published over the last year. We now have a documentation architecture and are actively building the core of a knowledge base that can help users get the best from PeeringDB. Kind regards, Leo Vegoda PeeringDB Product Manager _______________________________________________ Pdb-announce mailing list Pdb-announce(a)lists.peeringdb.com https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce

1 0

Need for historical prefix blacklist (`rogue' prefixes) information
by Amir Herzberg 01 Nov '21

01 Nov '21

Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), we need access to historical data of blacklisted prefixes (due to spam, DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we already have). Basically we want to measure if the overlap (and non-overlap) btw such `suspect' prefixes and ROV-Invalid prefixes. Any help would be appreciated. I'm not sure the list would be interested so I recommend you respond to me privately; if there are useful responses, I could post a summary to the list after few days (of collecting responses, if any). thanks and regards... Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook>

5 8

South Korea KT to pay USD$33.97 million for network outage
by Sean Donelan 01 Nov '21

01 Nov '21

https://www.koreatimes.co.kr/www/tech/2021/11/133_318025.html KT to pay W40 bil. in compensation for network outage KT will pay out up to 40 billion won ($33.97 million) in compensation to customers of its wired and wireless services, which underwent nationwide disruptions Oct. 25, the company said. [...] KT said it will pay compensation for 10 times the disruption time of 89 minutes... [...] NTT Docomo, AT&T, Verizon and T-Mobile caused disruptions in services for subscribers (customers) in recent years, but none offered compensation. "We are offering the greatest level of compensation compared to both local and foreign companies in the same industry," a KT official said. [...] The Ministry of Science and ICT said the mistake of an employee of a KT subcontractor caused the nationwide disruption.

1 0

possible rsync validation dos vuln
by Randy Bush 01 Nov '21

01 Nov '21

received this vuln notice four days before these children intend to disclose. so you can guess how inclined to embargo. randy From: Koen van Hove <k.w.vanhove(a)student.utwente.nl> Subject: CVD: Vulnerabilities in RPKI Validators To: randy(a)psg.com, sra(a)hactrn.net Cc: cert(a)ncsc.nl Date: Wed, 27 Oct 2021 14:59:21 -0700 Dear Randy Bush and Rob Austein, Apologies, this email was previously sent to the wrong email address. On behalf of the University of Twente and the National Cyber Security Centre of the Netherlands (NCSC-NL) we want to notify you of a Coordinated Vulnerability Disclosure for RPKI vulnerabilities that also impact rcynic developed by Dragon Research Labs. The vulnerabilities were discovered by scientific research on the implementation of RPKI validators. Together with you, the NCSC-NL, the University of Twente, and multiple other parties, we would like to come to a timely solution before the results of this research will be made public. More information about Coordinated Vulnerability Disclosure can be found here [1]. The vulnerabilities are classified as a denial of service vulnerability and impact multiple implementations of RPKI validators including rcynic. Since RPKI is of international interest we hope that you will work together with us on this CVD. The goal is to have fixes available before 1 November which will also be the date that the results of this research will become public. Before 1 November the information in the CVD, or the fact that a CVD is taking place, is to be kept strictly confidential. The fixes are to be released collectively on 1 November. Please let us know whether you agree to these terms, and want to participate in this CVD. If so, we will send you the details. We hope to hear from you. If there are any further questions, please let us know. Yours sincerely, Koen van Hove University of Twente [1] https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd - -- Koen van Hove -----BEGIN PGP SIGNATURE----- Version: FlowCrypt Email Encryption 8.1.5 Comment: Seamlessly send and receive encrypted email wsDzBAEBCgAGBQJhecu4ACEJEPnqm/++VTh9FiEE5Q3GCKqW0RQyUpA/+eqb /75VOH1CjwwAq8Hd0psDhfj6mL4X9ybLGogONpzFKYp9Okv9/CKzQvG4AkLR Cvrz3vHlQRKJP8I2PYSLZvtG9D/HXjjKcU+m24jjl2qbKKuSwprqQhLAqabN Md+RZFjQGve5Z4vtJsfhXKc4PhaAzMujVc4Mh5Mdbs4sFEdrub1hSnYKlcQV PvS/O9SpCYU0E0IC1I455HXxSXUtme+KHtzbGIWQe/mz4KpnZD2Me/Cr1LvG Od9izri0Qx5vF+kdpR51PEiwHgN+QkmnUP6Gkrca8TSC2x3ta9B1/ZprdCoZ ZYQ7QUFUAkfV+tKCMaBECNOrnDjw8E9GonvzmqpDHBtKBZ3LaxjZX/sxuuTC +Ele5nVeWW0ZFqrbanbPy9y1q04tFQd8ewdSN40iXdTj7Ha8GadUhcdSLWqJ cLmf71qUAvdwpp0Bt1nhExpU/bEtAaxfnEcTRDX43yUkZXSqV5BxYEyneSLj IvFV9AUi56Cx45ESkGRR1ASuCzoc8FCjRH7KOWnaL3fl =YQZI -----END PGP SIGNATURE-----

7 11

Re: Need for historical prefix blacklist (`rogue' prefixes)
by Jakob Heitz (jheitz) 01 Nov '21

01 Nov '21

It may be possible to create a fake certificate for a fake ROA. However, to do that requires a lot of steps to go right. First, the RSA private key needs to be derived from the public key. The quantum computer physics exists to do it. However, the known technology is massively behind and may never materialize. OTOH, it is a wide open field and someone may find a way to create enough qubits and entangle them all and keep them stable long enough to perform the calculation tomorrow. People have been trying for several years, so this is extremely unlikely. Second, relying parties need to be convinced/tricked into downloading the fake certificates. Since each certificate contains the publication points of its child certificates, the certs are chained together. The route to a publication point needs to be hacked to cause relying parties to access the fake publication point. A point was made that encrypted data can be captured and stored and then be decrypted later once the technology becomes available. This possibility is not useful for creating fake ROA certs. Therefore quantum resistant certificates will not be needed in advance of the development of quantum certificate crackers. Regards, Jakob. -----Original Message----- Date: Sat, 30 Oct 2021 19:57:25 -0500 From: "J. Hellenthal" <jhellenthal(a)dataix.net> He answered it completely. "You" worried about interception of RPKI exchange over the wire are failing to see that there is nothing there important to decrypt because the encryption in the transmission is not there ! And yet you've failed to even follow up to his question... "What's your point regarding your message? ROV does not use (nor needs) encryption." So maybe you could give some context on that so someone can steer you out of the wrong direction. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Oct 30, 2021, at 10:31, A Crisan <alina.florar(a)gmail.com> wrote: > > ? > Hi Matthew, > > Quantum computing exists as POCs, IBM being one of those advertising them and announced to extend their project. There are others on the market, Amazon advertised quantum computing as a service back in 2019: https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-…. The bottle neck of the current technology is scalability: we will not see QC as personal computing level just yet (to go in more detail, current technologies work at cryogenic temperatures, thus they are hyper expensive and not really scalable), but they exist and one could be imagine they are/will be used for various tasks. > > On the other hand, you've actually commented every word of my mail, minus the stated question. Thanks. > > Best Regards, > Dora Crisan > > > > > >> On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster <matthew(a)walster.org> wrote: >> >> >>> On Fri, 29 Oct 2021, 15:55 A Crisan, <alina.florar(a)gmail.com> wrote: >>> Hi Matthew, >>> I was reading the above exchange, and I do have a question linked to your last affirmation. To give you some context, the last 2021 ENISA report seem to suggest that internet traffic is "casually registered" by X actors to apply post Retrospective decryption (excerpt below). This would be at odds with your (deescalating) affirmation that hijacks are non-malicious and they are de-peered quickly, unless you pinpoint complete flux arrest only. Are there any reportings/indicators... that look into internet flux constant monitoring capabilities/capacities? Thanks. >> >> >> RPKI uses authentication not confidentiality. There is no encryption taking place, other than the signatures on the certificates etc. >> >>> Excerpt from the introduction: "What makes matters worse is that any cipher text intercepted by an attacker today can be decrypted by the attacker as soon as he has access to a large quantum computer (Retrospective decryption). >> >> >> Which do not exist (yet). >> >>> Analysis of Advanced Persistent Threats (APT) and Nation State capabilities, >> >> >> Buzzwords. >> >>> along with whistle blowers? revelations >> >>> have shown that threat actors can and are casually recording all Internet traffic in their data centers >> >> >> No they're not. It's just not possible or indeed necessary to duplicate everything at large scale. Perhaps with a large amount of filtering, certain flows would be captured, but in the days of pervasive TLS, this seems less and less worthwhile. >> >>> and that they select encrypted traffic as interesting and worth storing.This means that any data encrypted using any of the standard public-key systems today will need to be considered compromised once a quantum computer exists and there is no way to protect it retroactively, because a copy of the ciphertexts in the hands of the attacker. This means that data that needs to remain confidential after the arrival of quantum computers need to be encrypted with alternative means" >> >> >> None of this is relevant to RPKI (ROV) at all. In fact, it reads like the fevered dreams of a cyber security research student. What's your point regarding your message? ROV does not use (nor needs) encryption. >> >> M >>

1 0

Re: PCH Peering Survey 2021
by Adam Thompson 31 Oct '21

31 Oct '21

Question: if I have a written contract with a peer that covers the link and IP service in general, but that contract does not specifically discuss BGP or peering, is that a Yes or No? Also, how should I indicate "unknown" , particularly for the Written Contract field? -Adam Adam Thompson Consultant, Infrastructure Services [1593169877849] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/> ________________________________ From: NANOG on behalf of Bill Woodcock Sent: Friday, October 29, 2021 06:47 To: NANOG Subject: PCH Peering Survey 2021 Background: Five and ten years ago PCH conducted comprehensive global surveys characterizing Internet peering agreements. They are the only ones of their kind, and are relied upon by legislators and regulators throughout the world to understand the Internet interconnection landscape. Our write-ups of the prior surveys can be found here: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011… https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016… …and video of the NANOG presentation of the 2016 results is here: https://www.youtube.com/watch?v=lPuoBmxyXMc At the time of the 2011 survey, we committed to repeating the survey every five years, to provide time-series data about the direction peering trends take. We’re now conducting the third iteration of the survey. Among other things, the surveys have helped establish a better understanding of trends in: • The increasingly uniform global norms of interconnection • National preferences within the network operator community for country of governing law • The long tail of small networks which don’t yet support IPv6 routing • The significance of multilateral peering agreements in the density of the interconnection mesh These findings, particularly the first, have been invaluable in giving regulators in the vast majority of the world’s countries a data-driven basis for refraining from prescriptively regulating Internet interconnection. They have demonstrated in objective terms that the Internet self-regulates in a way that’s more globally uniform and closely harmonized than any coordination of national regulatory bodies could accomplish. Participation: The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world. Your participation ensures that your norms and ways of doing business are represented accurately and proportionately in the dataset. If you don’t participate, the way you do business will be less well-represented in the data, and will seem less normal to regulators and policy-makers. We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 4,331 networks in 96 countries, or 86% of the world’s ISPs at that time. In 2016, responses represented 10,794 networks in 148 countries, or 60% of the world’s ISPs in 2016. Our aim is to be equally inclusive this year. Since our principal method of soliciting participation is via NOG mailing lists, I’m afraid many of you will see this message several times, on different lists, for which we apologize. Privacy: In 2011 and 2016, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as was successfully employed the last two times. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed. The Survey: We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with: • Your peer’s ASN (peers only, not upstream transit providers or downstream customers) • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement") • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes) • Whether a jurisdiction of governing law is defined • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are) The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean [true,1,yes,y] or [false,0,no,n] Symmetric: Boolean [true,1,yes,y] or [false,0,no,n] Governing Law: ISO 3166 two-digit country-code, or empty IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n] For instance: 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr> We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we will protect your privacy by discarding the raw data of the responses, and only final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine. If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs. If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that. If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Finally, if there are questions you’d like us to try to answer when we analyze the data, please suggest them, and if there are any additional questions you’d like us to include in future iterations of the survey, please let us know so that we can consider including them in the 2026 survey. Please respond by replying to this email, by the middle of November, two weeks from now. Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community. -Bill Woodcock Executive Director Packet Clearing House

1 0

Comcast? Layer2 / ELAN
by Joe Carroll 29 Oct '21

29 Oct '21

Greetings Fellow Nanog'ers Are there any Comcast engineers in the group that could help to sort out a 10GB layer2 ELAN issue in Florida? We are short of cancelling this circuit that has been in for a couple of days. We cannot pass above 1GB on this circuit... 10GB SFPs on both ends, 10GB price, 1GB service... the team refuses to investigate, dispatch, or otherwise act in any way that is customer oriented. Regards, -Joe

3 2

Weekly Global IPv4 Routing Table Report
by cscora＠apnic.net 29 Oct '21

29 Oct '21

This is an automated weekly mailing describing the state of the Internet Global IPv4 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>. Global IPv4 Routing Table Report 04:00 +10GMT Sat 30 Oct, 2021 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 870998 Prefixes after maximum aggregation (per Origin AS): 330625 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 420290 Total ASes present in the Internet Routing Table: 72185 Prefixes per ASN: 12.07 Origin-only ASes present in the Internet Routing Table: 61995 Origin ASes announcing only one prefix: 25559 Transit ASes present in the Internet Routing Table: 10190 Transit-only ASes present in the Internet Routing Table: 349 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 53 Max AS path prepend of ASN (265020) 50 Prefixes from unregistered ASNs in the Routing Table: 906 Number of instances of unregistered ASNs: 910 Number of 32-bit ASNs allocated by the RIRs: 37687 Number of 32-bit ASNs visible in the Routing Table: 31261 Prefixes from 32-bit ASNs in the Routing Table: 146011 Number of bogon 32-bit ASNs visible in the Routing Table: 23 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 412 Number of addresses announced to Internet: 3071684096 Equivalent to 183 /8s, 22 /16s and 46 /24s Percentage of available address space announced: 83.0 Percentage of allocated address space announced: 83.0 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: 289786 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 232859 Total APNIC prefixes after maximum aggregation: 66598 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 228100 Unique aggregates announced from the APNIC address blocks: 92707 APNIC Region origin ASes present in the Internet Routing Table: 12077 APNIC Prefixes per ASN: 18.89 APNIC Region origin ASes announcing only one prefix: 3441 APNIC Region transit ASes present in the Internet Routing Table: 1700 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 37 Number of APNIC region 32-bit ASNs visible in the Routing Table: 7251 Number of APNIC addresses announced to Internet: 772994432 Equivalent to 46 /8s, 18 /16s and 245 /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-151865 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: 255120 Total ARIN prefixes after maximum aggregation: 117865 ARIN Deaggregation factor: 2.16 Prefixes being announced from the ARIN address blocks: 255232 Unique aggregates announced from the ARIN address blocks: 122364 ARIN Region origin ASes present in the Internet Routing Table: 18931 ARIN Prefixes per ASN: 13.48 ARIN Region origin ASes announcing only one prefix: 6851 ARIN Region transit ASes present in the Internet Routing Table: 1948 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 28 Number of ARIN region 32-bit ASNs visible in the Routing Table: 4179 Number of ARIN addresses announced to Internet: 1301625344 Equivalent to 77 /8s, 149 /16s and 58 /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: 242238 Total RIPE prefixes after maximum aggregation: 113310 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 238370 Unique aggregates announced from the RIPE address blocks: 146176 RIPE Region origin ASes present in the Internet Routing Table: 28088 RIPE Prefixes per ASN: 8.49 RIPE Region origin ASes announcing only one prefix: 12093 RIPE Region transit ASes present in the Internet Routing Table: 3920 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 38 Number of RIPE region 32-bit ASNs visible in the Routing Table: 10472 Number of RIPE addresses announced to Internet: 712202880 Equivalent to 42 /8s, 115 /16s and 90 /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: 113211 Total LACNIC prefixes after maximum aggregation: 26920 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 114105 Unique aggregates announced from the LACNIC address blocks: 47434 LACNIC Region origin ASes present in the Internet Routing Table: 10794 LACNIC Prefixes per ASN: 10.57 LACNIC Region origin ASes announcing only one prefix: 2626 LACNIC Region transit ASes present in the Internet Routing Table: 2129 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 53 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 8463 Number of LACNIC addresses announced to Internet: 176399872 Equivalent to 10 /8s, 131 /16s and 166 /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: 26664 Total AfriNIC prefixes after maximum aggregation: 5249 AfriNIC Deaggregation factor: 5.08 Prefixes being announced from the AfriNIC address blocks: 34779 Unique aggregates announced from the AfriNIC address blocks: 11255 AfriNIC Region origin ASes present in the Internet Routing Table: 1567 AfriNIC Prefixes per ASN: 22.19 AfriNIC Region origin ASes announcing only one prefix: 548 AfriNIC Region transit ASes present in the Internet Routing Table: 311 Average AfriNIC Region AS path length visible: 5.2 Max AfriNIC Region AS path length visible: 42 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 896 Number of AfriNIC addresses announced to Internet: 108183808 Equivalent to 6 /8s, 114 /16s and 193 /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 9808 8221 9000 57 CMNET-GD Guangdong Mobile Communication 7545 5844 787 684 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4663 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3590 1330 19 VIETEL-AS-AP Viettel Group, VN 7713 3499 1023 57 TELKOMNET-AS-AP PT Telekomunikasi Indon 45899 3058 1896 54 VNPT-AS-VN VNPT Corp, VN 4766 2508 11119 578 KIXS-AS-KR Korea Telecom, KR 9498 2165 472 236 BBIL-AP BHARTI Airtel Ltd., IN 45090 2126 1198 75 CNNIC-TENCENT-NET-AP Shenzhen Tencent C 4755 2124 429 203 TATACOMM-AS TATA Communications formerl 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 16509 5823 9989 2548 AMAZON-02, US 11492 4643 307 802 CABLEONE, US 22773 4060 3053 371 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3954 264 30 VIASAT-SP-BACKBONE, US 16625 3650 1886 2544 AKAMAI-AS, US 6327 3373 1318 69 SHAW, CA 749 2876 50735 2132 DNIC-AS-00749, US 30036 2594 375 164 MEDIACOM-ENTERPRISE-BUSINESS, US 209 2522 5028 444 CENTURYLINK-US-LEGACY-QWEST, US 7018 2246 24165 1432 ATT-INTERNET4, 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 12479 6877 1726 143 UNI2-AS, ES 20940 3912 3348 213 AKAMAI-ASN1, NL 8551 3289 378 39 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 39891 3271 187 23 ALJAWWALSTC-AS, SA 12389 2934 2283 898 ROSTELECOM-AS, RU 9009 2504 259 1321 M247, GB 34984 2238 358 602 TELLCOM-AS, TR 58224 1696 903 577 TCI, IR 61317 1683 224 938 ASDETUK www.heficed.com, GB 13188 1610 100 27 TRIOLAN, UA 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 10584 3461 577 Uninet S.A. de C.V., MX 10620 3249 492 818 Telmex Colombia S.A., CO 11830 2469 369 62 Instituto Costarricense de Electricidad 13999 1634 288 453 Mega Cable, S.A. de C.V., MX 6503 1526 359 473 Axtel, S.A.B. de C.V., MX 28573 1446 2310 256 CLARO S.A., BR 3816 1240 651 153 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 26615 1132 2351 137 TIM SA, BR 6147 1098 369 22 Telefonica del Peru S.A.A., PE 11664 958 187 441 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 1605 393 21 LINKdotNET-AS, EG 24835 1552 503 33 RAYA-AS, EG 36992 1272 1414 268 ETISALAT-MISR, EG 36903 1183 537 110 MT-MPLS, MA 29571 812 68 11 ORANGE-COTE-IVOIRE, CI 36935 670 523 44 Vodafone-, EG 6713 611 1863 34 IAM-AS, MA 15399 514 50 31 WANANCHI-, KE 37342 470 32 1 MOVITEL, MZ 2018 342 319 73 TENET-1, ZA 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 10584 3461 577 Uninet S.A. de C.V., MX 9808 8221 9000 57 CMNET-GD Guangdong Mobile Communication 12479 6877 1726 143 UNI2-AS, ES 7545 5844 787 684 TPG-INTERNET-AP TPG Telecom Limited, AU 16509 5823 9989 2548 AMAZON-02, US 4538 4663 4192 74 ERX-CERNET-BKB China Education and Rese 11492 4643 307 802 CABLEONE, US 22773 4060 3053 371 ASN-CXA-ALL-CCI-22773-RDC, US 7155 3954 264 30 VIASAT-SP-BACKBONE, US 20940 3912 3348 213 AKAMAI-ASN1, NL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 8221 8164 CMNET-GD Guangdong Mobile Communication Co.Ltd. 12479 6877 6734 UNI2-AS, ES 7545 5844 5160 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4663 4589 ERX-CERNET-BKB China Education and Research Net 7155 3954 3924 VIASAT-SP-BACKBONE, US 11492 4643 3841 CABLEONE, US 20940 3912 3699 AKAMAI-ASN1, NL 22773 4060 3689 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3590 3571 VIETEL-AS-AP Viettel Group, VN 7713 3499 3442 TELKOMNET-AS-AP PT Telekomunikasi Indonesia, ID 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 398418 UNALLOCATED 8.2.200.0/24 2914 NTT-COMMUNICATIONS-2914, US 46990 UNALLOCATED 8.5.242.0/23 3356 LEVEL3, US 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 46887 LIGHTOWER, US 18604 UNALLOCATED 8.25.204.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 54338 UNALLOCATED 8.33.241.0/24 6461 ZAYO-6461, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 1782 UNALLOCATED 8.42.19.0/24 46887 LIGHTOWER, US 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, 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.132.208.0/24 Origin: 7850 CITYLINKFIBER, US 23.132.208.0/24 Transit: 15164 UPNLLC, US 23.141.0.0/24 Origin: 395350 UNASSIGNED 23.141.0.0/24 Transit: 11426 TWC-11426-CAROLINAS, US 27.100.7.0/24 Origin: 56096 UNASSIGNED 27.100.7.0/24 Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 41.57.124.0/22 Origin: 37442 UNASSIGNED 41.57.124.0/22 Transit: 174 COGENT-174, US 41.57.124.0/23 Origin: 37442 UNASSIGNED 41.57.124.0/23 Transit: 37204 TELONE, ZW 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:16 /9:13 /10:41 /11:99 /12:300 /13:597 /14:1214 /15:2047 /16:13590 /17:8320 /18:14037 /19:25517 /20:43160 /21:51181 /22:107432 /23:93998 /24:507983 /25:1453 /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 12479 5840 6877 UNI2-AS, ES 8151 4384 10584 Uninet S.A. de C.V., MX 11492 3597 4643 CABLEONE, US 6327 3181 3373 SHAW, CA 7155 3044 3954 VIASAT-SP-BACKBONE, US 22773 3008 4060 ASN-CXA-ALL-CCI-22773-RDC, US 39891 2807 3271 ALJAWWALSTC-AS, SA 8551 2754 3289 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 2247 2594 MEDIACOM-ENTERPRISE-BUSINESS, US 11830 1921 2469 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1922 2:1056 3:145 4:19 5:3660 6:100 7:5 8:1554 9:1 11:172 12:1712 13:404 14:2292 15:119 16:25 17:371 18:123 20:130 21:4 22:188 23:5250 24:2406 25:2 27:2549 29:19 31:2375 32:106 34:1 35:47 36:1725 37:3910 38:2339 39:611 40:149 41:3820 42:1037 43:2072 44:290 45:15564 46:3727 47:321 49:1677 50:1850 51:100 52:1308 54:284 55:739 56:4 57:55 58:1741 59:1185 60:935 61:2340 62:2345 63:1958 64:5421 65:2355 66:4939 67:2874 68:1168 69:4102 70:1354 71:678 72:3155 74:2627 75:1496 76:699 77:2061 78:1736 79:2589 80:1864 81:1514 82:1379 83:1173 84:1296 85:2815 86:713 87:1870 88:982 89:3094 90:497 91:7440 92:1835 93:2570 94:3158 95:3568 96:1301 97:348 98:977 99:933 100:75 101:1035 102:1750 103:27310 104:4062 105:437 106:829 107:2391 108:739 109:3916 110:2048 111:3130 112:1964 113:1413 114:1507 115:1921 116:1894 117:2421 118:2328 119:1885 120:1610 121:1084 122:2536 123:2130 124:1596 125:2063 128:1396 129:1104 130:910 131:2054 132:745 133:364 134:1888 135:319 136:792 137:865 138:2413 139:1208 140:828 141:1290 142:1218 143:1381 144:1273 145:327 146:1567 147:1460 148:2221 149:1582 150:833 151:1091 152:1657 153:434 154:3207 155:1354 156:1802 157:1180 158:982 159:2045 160:2311 161:1258 162:3357 163:1108 164:1656 165:1474 166:604 167:1652 168:3652 169:679 170:4344 171:804 172:2776 173:3006 174:1005 175:1125 176:3372 177:4498 178:3017 179:1931 180:2262 181:2611 182:3139 183:2019 184:2417 185:18965 186:4207 187:3489 188:3580 189:3080 190:8649 191:1305 192:10959 193:8408 194:6849 195:4882 196:2876 197:2181 198:6084 199:5981 200:7382 201:5623 202:10522 203:10023 204:4530 205:3384 206:3798 207:3374 208:4005 209:4726 210:4217 211:2434 212:3747 213:3389 214:1155 215:64 216:6385 217:2623 218:1230 219:647 220:1955 221:975 222:852 223:2083 End of report

1 0

PCH Peering Survey 2021
by Bill Woodcock 29 Oct '21

29 Oct '21

Background: Five and ten years ago PCH conducted comprehensive global surveys characterizing Internet peering agreements. They are the only ones of their kind, and are relied upon by legislators and regulators throughout the world to understand the Internet interconnection landscape. Our write-ups of the prior surveys can be found here: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011… <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016… <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016…> …and video of the NANOG presentation of the 2016 results is here: https://www.youtube.com/watch?v=lPuoBmxyXMc <https://www.youtube.com/watch?v=lPuoBmxyXMc> At the time of the 2011 survey, we committed to repeating the survey every five years, to provide time-series data about the direction peering trends take. We’re now conducting the third iteration of the survey. Among other things, the surveys have helped establish a better understanding of trends in: • The increasingly uniform global norms of interconnection • National preferences within the network operator community for country of governing law • The long tail of small networks which don’t yet support IPv6 routing • The significance of multilateral peering agreements in the density of the interconnection mesh These findings, particularly the first, have been invaluable in giving regulators in the vast majority of the world’s countries a data-driven basis for refraining from prescriptively regulating Internet interconnection. They have demonstrated in objective terms that the Internet self-regulates in a way that’s more globally uniform and closely harmonized than any coordination of national regulatory bodies could accomplish. Participation: The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world. Your participation ensures that your norms and ways of doing business are represented accurately and proportionately in the dataset. If you don’t participate, the way you do business will be less well-represented in the data, and will seem less normal to regulators and policy-makers. We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 4,331 networks in 96 countries, or 86% of the world’s ISPs at that time. In 2016, responses represented 10,794 networks in 148 countries, or 60% of the world’s ISPs in 2016. Our aim is to be equally inclusive this year. Since our principal method of soliciting participation is via NOG mailing lists, I’m afraid many of you will see this message several times, on different lists, for which we apologize. Privacy: In 2011 and 2016, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as was successfully employed the last two times. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed. The Survey: We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with: • Your peer’s ASN (peers only, not upstream transit providers or downstream customers) • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement") • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes) • Whether a jurisdiction of governing law is defined • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are) The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean [true,1,yes,y] or [false,0,no,n] Symmetric: Boolean [true,1,yes,y] or [false,0,no,n] Governing Law: ISO 3166 two-digit country-code, or empty IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n] For instance: 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr> We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we will protect your privacy by discarding the raw data of the responses, and only final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine. If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs. If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that. If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Finally, if there are questions you’d like us to try to answer when we analyze the data, please suggest them, and if there are any additional questions you’d like us to include in future iterations of the survey, please let us know so that we can consider including them in the 2026 survey. Please respond by replying to this email, by the middle of November, two weeks from now. Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community. -Bill Woodcock Executive Director Packet Clearing House

2 2

What are best practices for RPKI ROV in transit networks....
by ssw＠iu.edu 29 Oct '21

29 Oct '21

Greetings, We seek input on best practices for implementing RPKI ROV in a transit (partial transit) network. The Internet2 network provides partial transit for many of the K-12 and higher education institutions in the US. Our customer routes number just over 6,000. We work with our customers to assist with the adoption of MANRS, including creating RPKI ROAs for their resources. At some point in the future, we'd like to implement RPKI route origin validation (e.g., dropping invalids). Given that some routes may have mistaken ROAs that resolve to an invalid state, is there a standard/best practice for processing exceptions? Or, do transit providers that implement ROAs drop all routes that are invalid? Thanks, Steve

5 4