Re: Dodgy AS327933 ...?

2023-08-11 Thread August Yang via NANOG
BGP was indeed designed in an era when trust was implicit. Introducing ASPA to sign a cryptographic list of authorized providers steps in the right direction. By validating both AS_PATH and route origin, the chances of BGP hijack and misconfigurations can be substantially reduced.

Weekly Global IPv4 Routing Table Report

2023-08-11 Thread Routing Table Analysis Role Account
This is an automated weekly mailing describing the state of the 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

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 12:56, Nick Hilliard wrote: bgp is a policy based distance vector protocol. If you can't adjust the primary inter-domain metric to handle your policy requirements, it's not much use. I am not talking about appending one's own AS in the AS_PATH. I am talking about appending

Re: Friday Thanks

2023-08-11 Thread Graham Johnston via NANOG
Sorry, NTT, I didn't mean to leave you out, you were great too - Thanks. From: NANOG on behalf of Graham Johnston via NANOG Sent: Friday, August 11, 2023 10:53 AM To: nanog@nanog.org Subject: Friday Thanks I've been busy over the last few days trying to

Re: Dodgy AS327933 ...?

2023-08-11 Thread Jay Hennigan
On 8/11/23 02:26, Nick Hilliard wrote: If your asn is 327933, then: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2 ... will produce: "327933 327933", and: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2 ... will produce: "327933 2". Routeros does

Re: Friday Thanks

2023-08-11 Thread Job Snijders via NANOG
On Fri, 11 Aug 2023 at 17:54, Graham Johnston via NANOG wrote: > I've been busy over the last few days trying to clean up IRR information > for our subnets and issue ROAs for our address space. Invariably I came > across stale entries in various IRR databases. They aren't really hurting > me,

Friday Thanks

2023-08-11 Thread Graham Johnston via NANOG
I've been busy over the last few days trying to clean up IRR information for our subnets and issue ROAs for our address space. Invariably I came across stale entries in various IRR databases. They aren't really hurting me, but I feel like there shouldn't be competing incorrect information out

Re: NTP Sync Issue Across Tata (Europe)

2023-08-11 Thread Masataka Ohta
Forrest Christian (List Account) wrote: The NIST time servers do NOT get their time from GPS. No, of course. I know it very well. However, as I wrote: > But, additionally relying on remote servers (including those > provided by NIST) is subject to DOS attacks. the (mostly wired) Internet

Re: NTP Sync Issue Across Tata (Europe)

2023-08-11 Thread Forrest Christian (List Account)
The NIST time servers do NOT get their time from GPS. NIST, like several government standards agencies and other research labs around the globe, run an ensemble of high precision atomic clocks. In the case of NIST, they use the ensemble to produce the timescale UTC(NIST) at their Boulder,

Re: Dodgy AS327933 ...?

2023-08-11 Thread Nick Hilliard
Mark Tinka wrote on 11/08/2023 10:33: It is not terribly clever of Mikrotik to have two commands that do different things be that close in syntax. no, indeed. That said, why are we giving the routers the ability to manually generate AS_PATH's? On any router OS, this is simply asking for it.

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 11:26, Nick Hilliard wrote: If your asn is 327933, then: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2 ... will produce: "327933 327933", and: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2 ... will produce: "327933 2". Routeros

Re: NTP Sync Issue Across Tata (Europe)

2023-08-11 Thread Masataka Ohta
Forrest Christian (List Account) wrote: The recommendation tends to be the following: 1) Run your GPS-derived NTP appliances, but DO NOT point end-user clients at it. 2) Run a set of internal NTPd servers, and configure them to pull time from all of your GPS-derived NTP servers, AND trusted

Re: Dodgy AS327933 ...?

2023-08-11 Thread Nick Hilliard
Mark Tinka wrote on 11/08/2023 10:17: So how would one fumble it to the degree where a fat-finger results in what should be a prepend becoming an AS_PATH? Genuine question - I have zero experience with Mikrotik in an SP role. If your asn is 327933, then: add chain=foo prefix=192.0.2.0/24

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 11:08, Nick Hilliard wrote: yep, sure did.  Check out the "set-bgp-prepend" action on routeros - it's right next to "set-bgp-prepend-path". https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters So how would one fumble it to the degree where a fat-finger results in

Re: Dodgy AS327933 ...?

2023-08-11 Thread Nick Hilliard
Mark Tinka wrote on 11/08/2023 09:43: Did I miss the memo where vendors went from explicitly defining the AS multiple times to determine the number of prepends, to, this :-)? yep, sure did. Check out the "set-bgp-prepend" action on routeros - it's right next to "set-bgp-prepend-path".

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 10:15, b...@uu3.net wrote: Haha :) you are right. I just checked Caida AS ranking: http://as-rank.uu3.net/?as=2 A lot of "providers" for UDEL-DCN. Yeah right.. They all indeed probably try to prepend their AS 2 times ending up having ASN 2 in path. Did I miss the memo where

Re: Dodgy AS327933 ...?

2023-08-11 Thread borg
Haha :) you are right. I just checked Caida AS ranking: http://as-rank.uu3.net/?as=2 A lot of "providers" for UDEL-DCN. Yeah right.. They all indeed probably try to prepend their AS 2 times ending up having ASN 2 in path. -- Original message -- From: Mike Davis To: