December 2022 - NANOG - lists.nanog.org

Re: ECN
by Toke Høiland-Jørgensen 25 Mar '25

25 Mar '25

On 13 November 2019 17:20:18 CET, Matt Corallo <netadmin(a)as397444.net> wrote: >This sounds like a bug on Cloudflare’s end (cause trying to do anycast >TCP is... out of spec to say the least), not a bug in ECN/ECMP. Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will split the flow over multiple paths; avoiding that is the whole point of doing the flow-based hashing in the first place. Anycast "only" turns a potential degradation of TCP performance into a hard failure... :) -Toke

6 8

Issue with Geolocation in Virginia US
by Raja Sekhar Gullapalli 04 Jan '24

04 Jan '24

Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja

8 13

FW: softlayer.com
by Travis Garrison 23 Sep '23

23 Sep '23

Traceroute from here if it helps Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms [REDACTED] 2 <1 ms <1 ms <1 ms [REDACTED] 3 1 ms 1 ms <1 ms [REDACTED] 4 1 ms <1 ms <1 ms [REDACTED] 5 6 ms 6 ms 6 ms v313.core1.mci3.he.net [216.218.213.141] 6 16 ms 16 ms 16 ms 100ge10-2.core1.dal1.he.net [184.105.81.206] 7 26 ms 26 ms 26 ms xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78] 8 40 ms 39 ms 40 ms 207.88.14.198.ptr.us.xo.net [207.88.14.198] 9 40 ms 39 ms 40 ms 207.88.12.178.ptr.us.xo.net [207.88.12.178] 10 39 ms 39 ms 39 ms 216.156.16.239.ptr.us.xo.net [216.156.16.239] 11 48 ms 48 ms 48 ms ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198] 12 41 ms 41 ms 41 ms occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa [192.131.57.6] 13 * * * Request timed out. Thanks Travis From: NANOG <nanog-bounces(a)nanog.org<mailto:nanog-bounces@nanog.org>> On Behalf Of Siyuan Miao Sent: Friday, March 22, 2019 9:22 AM To: Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> Cc: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Re: softlayer.com Perhaps it won't work because their customer support will ask you for bi-directional traceroute and refused to forward to backbone team. Then they'll say it's not their fault and you can see the packet is dropped outside our network. Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle in case someone needs it: aveline@iad02-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 17:20:42 2019 HOST: iad02-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 1.4 1.5 0.8 3.7 1.0 2.|-- ae13.dar02.wdc01.networklayer.com<http://ae13.dar02.wdc01.networklayer.com> 0.0% 10 0.5 3.3 0.4 28.6 8.8 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com<http://ae9.bbr01.eq01.wdc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 1.0 0.0 4.|-- eqix-dc5.intellifiber.com<http://eqix-dc5.intellifiber.com> 0.0% 10 0.8 1.2 0.8 2.2 0.3 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net<http://ae13-0.cr02.asbn01-va.us.windstream.net> 0.0% 10 0.9 0.9 0.9 1.0 0.0 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net<http://ae11-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 15.6 16.1 15.6 17.4 0.5 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 17.4 16.1 15.9 17.4 0.3 8.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 24.7 24.8 24.6 24.9 0.0 9.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 22.6 22.8 22.5 23.8 0.0 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sjc03-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 16:21:04 2019 HOST: sjc03-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 2.4 2.0 0.3 14.3 4.3 2.|-- ae0.dar02.sjc01.networklayer.com<http://ae0.dar02.sjc01.networklayer.com> 0.0% 10 1.0 0.5 0.3 1.3 0.0 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com<http://ae9.bbr01.eq01.sjc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 0.9 0.0 4.|-- eqix-sv1.windstream.com<http://eqix-sv1.windstream.com> 0.0% 10 0.9 0.9 0.8 1.1 0.0 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net<http://ae6-0.cr02.lsaj01-ca.us.windstream.net> 0.0% 10 11.6 11.5 11.5 11.6 0.0 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net<http://ae-11-0.cr01.dlls01-tx.us.windstream.net> 0.0% 10 42.6 42.7 42.5 43.4 0.0 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net<http://ae7-0.cr02.atln02-ga.us.windstream.net> 0.0% 10 64.0 65.6 63.9 74.2 3.4 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net<http://ae1-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 62.3 62.7 62.2 66.9 1.5 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.9 72.0 71.9 72.2 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 69.9 68.8 68.6 69.9 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sea04-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 08:19:09 2019 HOST: sea04-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 0.7 1.2 0.7 1.8 0.0 2.|-- ae12.dar02.sr01.sea01.networklayer.com<http://ae12.dar02.sr01.sea01.networklayer.com> 0.0% 10 0.6 0.7 0.5 1.3 0.0 3.|-- ae9.bbr01.wb01.sea02.networklayer.com<http://ae9.bbr01.wb01.sea02.networklayer.com> 0.0% 10 1.2 1.0 0.7 1.5 0.0 4.|-- six.seattle-wa.us.windstream.net<http://six.seattle-wa.us.windstream.net> 0.0% 10 1.5 1.0 0.7 1.7 0.0 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net<http://ae12-0.cr01.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.2 41.0 41.6 0.0 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net<http://ae17-0.cr02.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.4 41.1 42.0 0.0 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net<http://ae10-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 63.8 64.4 63.5 71.1 2.3 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 63.7 63.7 63.5 64.0 0.0 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.6 71.8 71.5 72.8 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 71.8 70.8 70.2 71.8 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 Regards, Siyuan Miao On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> wrote: This is the best approach. Have run into this problem a few times and had zero success getting the filters removed without having SL customers log tickets with support. Verbiage needs to be “this prefix is blocked, please escalate to your backbone team”. Sent from my iPhone On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) <lists(a)packetflux.com<mailto:lists@packetflux.com>> wrote: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Still looking for anyone from softlayer.com<http://softlayer.com> It has been a challenge. Anything hosted by softlayer.com<http://softlayer.com> is being blocked. Here is a small list so far windowbook.tpondemand.com<http://windowbook.tpondemand.com> ahainstructornetwork.americanheart.org<http://ahainstructornetwork.americanheart.org> clover.com<http://clover.com> Cebroker.com<http://Cebroker.com> Softlayer.com<http://Softlayer.com> indeed.com<http://indeed.com> & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John

3 2

Providing geofeed info to Google
by Hugo Slabbert 18 Sep '23

18 Sep '23

Google folks: I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html. Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal? -- Hugo Slabbert

6 8

SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot
by Gavin Henry 04 Jul '23

04 Jul '23

Hi all, I hope you don't mind the post, but thought this might be of use and in the spirit of release early, release often I've done an alpha release: https://github.com/SentryPeer/SentryPeer There's a presentation too if you'd like to watch/read where I hope to go with this: https://blog.tadsummit.com/2021/11/17/sentrypeer/ Working on the API and web UI next, then the p2p part of it. Feel free to submit any feature requests or have a play :-) Thanks for reading and any feedback is welcome! -- Kind Regards, Gavin Henry.

3 7

afrinic rpki issue
by Randy Bush 14 Jun '23

14 Jun '23

From: PacketVis <notifications(a)packetvis.com> Date: Sun, 20 Nov 2022 04:30:44 +0000 Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs disappeared from afrinic See more details about the event: https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3…

5 9

Re: Upstream bandwidth usage
by Mel Beckman 27 Feb '23

27 Feb '23

Adam, Your point on asymmetrical technologies is excellent. But you may not be aware that residential optical fiber is also asymmetrical. For example, GPON, the latest ITU specified PON standard, and the most widely deployed, calls for a 2.4 Gbps downstream and a 1.25 Gbps upstream optical line rate. -mel > On Jun 9, 2022, at 3:08 PM, Adam Thompson <athompson(a)merlin.mb.ca> wrote: > However, if you're talking about fiber service, it's pretty much pure marketing-dept-driven BS, combined with some vague justification of not letting TOR nodes or copyright-ignoring seeders/Warez-providers/etc. overwhelm the network in unexpected ways.

18 25

202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 16 Jan '23

16 Jan '23

Dear Colleagues: 0) I was made aware of a recent discussion on this Forum that cited our work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4). (Please see, at the end of this MSG, the URL to the discussion and the highlighted text where the citation was made.) 1) As the lead investigator of the EzIP Project, I would like to formally introduce our solution by bringing your attention to an overview whitepaper: https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf In a nutshell, EzIP proposes to disable the program codes in current routers that have been disabling the use of the 240/4 NetBlock. The cost of this software engineering should be minimal. The EzIP deployment architecture is the same as that of the existing CG-NAT (Carrier Grade Network Address Translation). Consequently, there is no need to modify any hardware equipment. There is an online setup description (Reference II), called RAN (Regional Area Network), that demonstrates the feasibility of this approach. 2) There are additional consequential benefits by deploying EzIP, such as those mentioned by our comment to Reference III in the above whitepaper. I look forward to addressing your thoughts. Regards, Abe (2022-03-07 17:14 EST) VP Engineering Avinta Communications, Inc. Milpitas, CA 95035 USA +1(408)942-1485 Skype: Abraham.Y.Chen eMail: AYChen(a)Avinta.com WebSite: www.Avinta.com *********************** https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html Class D addresses? was: Redploying most of 127/8 as unicast public *Greg Skinner* gregskinner0 at icloud.com <mailto:nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E> /Mon Nov 29 18:47:14 UTC 2021/ * Previous message (by thread): Class D addresses? was: Redploying most of 127/8 as unicast public <https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html> * Next message (by thread): Class E addresses? 240/4 history <https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html> * *Messages sorted by:* [ date ] <https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766> [ thread ] <https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766> [ subject ] <https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766> [ author ] <https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766> ------------------------------------------------------------------------ >/On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />//>/On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />>>/I like research but what would the RIRs study? The percentage of the />>//>>/Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC />>/and they said similar things when 1.1.1.0/24 was stood up as an />>/experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular. />//>/Hi David, />//>/I don't recall there being any equipment or software compatibility />/concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As />/I recall it, there were concerns with prior local use and potential />/trash traffic. It seemed likely those concerns could be addressed with />/experiments, and the experiments in fact addressed them. />//>/The prior local use worry reared its head again with 240/4 but given />/the prior experience with 1.0.0.0/8 I don't personally believe we need />/to re-run that experiment just because the numbers are part of a />/different block. />//>//>>/Seems to me that a number of folks on this list and during this />>/discussion would disagree with a blanket assertion that 240/4 />>/is “dysfunctional on the 2021 Internet” - some of them even />>/wrote a draft discussing the possibility. />//>/Line them up. Show of hands. Who really thinks that if we assign />/240.0.0.1 to a customer tomorrow without waiting for anyone to clean />/up their software and hardware, you won't get enough complaints about />/things not working that you have to take it back and assign a />/different address instead? />//>//>>/1. Move 240/4 from "reserved" to "unallocated unicast" />>//>>/OK, but this seems like a quibble. The status for 240/4 is “ />>/RESERVED: designated by the IETF for specific non-global-unicast />>/purposes as noted.” The “as noted” part is “Future Use”. />//>/It's not a quibble. Some vendors take the current status to mean />/"treat it like unicast until we're told otherwise." Others take the />/status to mean, "packets with these addresses are bogons without a />/defined routing behavior until we're told otherwise." The result is />/incompatible behavior between vendors. Changing that direction to />/"treat it like unicast" without ambiguity is not a quibble. />//>/Regards, />/Bill Herrin />//>/-- />/William Herrin />/bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog> />/https://bill.herrin.us/ / For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo <https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/>, a draft proposing another way to make additional IPv4 address space available I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation <https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described could be deployed. I noticed that the presentation made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area. The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors. —gregbo ******************* -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

70 306

Google Speed Test
by Mike Hammett 03 Jan '23

03 Jan '23

Does AS15169 have a speed test? It would be nice to gauge the capacity to a particular network that's something laypeople could do. I could host something in GCP myself, but cloud is expensive. ----- Mike Hammett [ http://www.ics-il.com/ | Intelligent Computing Solutions ] [ https://www.facebook.com/ICSIL ] [ https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [ https://www.linkedin.com/company/intelligent-computing-solutions ] [ https://twitter.com/ICSIL ] [ http://www.midwest-ix.com/ | Midwest Internet Exchange ] [ https://www.facebook.com/mdwestix ] [ https://www.linkedin.com/company/midwest-internet-exchange ] [ https://twitter.com/mdwestix ] [ http://www.thebrotherswisp.com/ | The Brothers WISP ] [ https://www.facebook.com/thebrotherswisp ] [ https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg ]

16 27

RPKI's 2022 Year in Review: growth & innovation
by Job Snijders 31 Dec '22

31 Dec '22

Dear all, With 2023 at our doorstep, I'd like to share some perspective on how RPKI evolved in the year 2022. Impact on the Global Internet Routing System ============================================ Decision makers might wonder: is investing time and resources worth it? What is the effectiveness of RPKI Route Origin Validation (RPKI-ROV)? In the last year a number of interesting reports were published. Even though less than half of BGP routes is covered by RPKI ROAs [6], based on flow data, Kentik estimates [2] nowadays the majority of IP traffic is destined towards RPKI-valid BGP routes. Their follow-up report [3] (analysing BGP control-plane data) suggests that evaluation of a BGP route as RPKI-invalid reduces its propagation by anywhere between one half to two thirds. Cloudflare [4] published a report analysing data-plane connectivity between a select number of ASes and RPKI-invalid destinations: they estimate 6.5% (lower-bound) of residential Internet users enjoy the benefits their ISP doing RPKI-ROV. Another experiment report [5] (focussed on data-plane connectivity between validators and RPKI-valid/RPKI-invalid destinations), concluded the existence of RPKI ROAs helped move 75% of test traffic towards the correct destination. The above metrics might appear all over the place (6.5% up to 75%), but keep in mind these analyses are not mutually exclusive. Observations of the Internet's topology are a function of the observer's vantage point. All the referenced reports agree on key points: * ROAs have a measurable & significant impact on global IP traffic delivery * RPKI-ROV helps reduce the "blast radius" of BGP routing incidents * They recommend to continue the global deployment of RPKI-ROV (rejecting RPKI-invalid BGP routes), and create ROAs for all IP address space. Year to Year Growth of the distributed RPKI database ==================================================== In comparison to "effectiveness", the bare existence, size, contents, and number of Signed Objects in the globally distributed RPKI repository system is much easier to quantify. The below table was constructed by comparing two December 31st RPKIviews.org snapshots [1] of validated RPKI caches, primed with the ARIN, AFRINIC, APNIC, LACNIC, and RIPE Trust Anchors. 2021-12-31 2022-12-31 Total cache size (KiB): 996,216 1,240,572 (+24%) Total number of files (objects): 192,503 242,969 (+26%) Publication servers (FQDNs): 36 52 (+44%) Certification authorities: 28,328 34,901 (+23%) Route origin authorizations: 101,645 138,323 (+36%) Unique VRPs: 302,025 390,752 (+29%) IPv4 addresses covered: 1,139,561,719 1,354,270,410 (+19%) IPv6 addresses covered: 7,499,405,083 9,446,853,925 (+26%) *10^24 Unique origin ASNs in ROAs: 27,174 34,455 (+27%) A healthy growth rate across the board! With the ubiquitous availability of "Publication as a Service" hosted by RIRs, I expect (and hope!) the growth of the number of distinct publication servers to stall, or even drop in 2023. The number of Certification Authorities (CAs) closely corresponds to the number of RIR members (RIR customers) who opted to enable RPKI services for their Internet Number Resources, making it a useful proxy metric to understand how many organisations are creating RPKI ROAs. A single Route origin authorizations (ROA) can contain one or more Validated ROA Payloads (VRPs), and one or multiple ROAs can contain the exact same VRP information. "Unique" in the above table indicates the metric's underlaying data was deduplicated. Each ROA can only contain a single Origin ASN. Multiple ROAs can refer to the same Origin ASN value. Innovation through Standardisation ================================== The IETF SIDROPS [7] working group (the designated forum in which volunteers collaborate to define and specify open standards for RPKI and RPKI-based technologies) was fairly productive in 2022 and managed to publish 5 RFCs: RFC 9286 - Manifests for the RPKI (revision) RFC 9255 - The 'I' in RPKI Does Not Stand for Identity (clarification) RFC 9319 - The Use of maxLength in the RPKI (clarification) RFC 9323 - A Profile for RPKI Signed Checklists (RSCs) (innovation) RFC 9324 - Policy Based on the RPKI without Route Refresh (innovation) The above body of work consists mostly of revisions of older work or clarifications on how to use the RPKI, to me this demonstrates a somewhat conservative approach (rather than innovation at breakneck speed), which I consider a good thing. Outlook & Conclusion ==================== Now that globally Route Origin Validation has advanced as far as it has, the next obvious target is BGP path validation, to mitigate two distinct problems: BGP route leaks and BGP AS_PATH spoofing. Both painful to network operators! While projects like OpenBSD's validator rpki-client and NLNetLabs' signer Krill made significant headway to support both BGPsec and ASPA, the industry as a whole still (especially the BGP implementations) have a decent chunk of work ahead. Once the freshly-created software runs on BGP routers and RIR portals offer BGPsec+ASPA functionality, operators need to investigate initial deployment strategies. RPKI clearly is the technology of choice to improve safety and security of the global Internet routing system. Adoption of RPKI continues to grow. I'm excited to learn how far we'll be at the end of 2023! Kind regards, Job Sources: [1]: RPKI Views - http://rpkiviews.org/ http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2021/12/31/… http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2022/12/31/… [2]: https://www.kentik.com/blog/measuring-rpki-rov-adoption-with-netflow/ Bias warning: source data compiled from Kentik customer data [3]: https://www.kentik.com/blog/how-much-does-rpki-rov-reduce-the-propagation-o… Bias warning: source data compiled from the Route Views BGP collector project [4]: https://blog.cloudflare.com/rpki-updates-data/ Caveat: the methodology might arrive at a lower coverage adoption rating due to suspected erroneous classification of RPKI-ROV enabled networks as 'non-validating', in case a default route (route of last resort) is present which facilitated data-plane conduit. The presence of default routes does not in any way diminish the value of RPKI-ROV, but does distort some types of measurement. [5]: https://labs.ripe.net/author/koen-van-hove/where-did-my-packet-go-measuring… [6]: https://rpki-monitor.antd.nist.gov/ROV/20221231.00/All/All/4 [7]: https://datatracker.ietf.org/wg/sidrops/about/

1 0