Re: Dodgy AS327933 ...?
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. https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ On 2023-08-11 13:51, Mark Tinka wrote: 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 someone else's AS in the AS_PATH. To be fair, I have never had to do that, since I've always thought it would be considered bad form. But I suspect that on the simple BGP mechanics of it, no vendor would be able to prevent that in any meaningful way. Then again, path hijacking likely wasn't a thought at the time the Border Gateway Protocol was being conceived. Mark. -- August
Weekly Global IPv4 Routing Table Report
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 bgp-st...@lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith . IPv4 Routing Table Report 04:00 +10GMT Sat 12 Aug, 2023 BGP Table (Global) as seen in Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 927197 Prefixes after maximum aggregation (per Origin AS): 351848 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 452652 Total ASes present in the Internet Routing Table: 74689 Prefixes per ASN: 12.41 Origin-only ASes present in the Internet Routing Table: 64139 Origin ASes announcing only one prefix: 26321 Transit ASes present in the Internet Routing Table: 10550 Transit-only ASes present in the Internet Routing Table:460 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 68 Max AS path prepend of ASN (263725) 64 Prefixes from unregistered ASNs in the Routing Table: 1089 Number of instances of unregistered ASNs: 1091 Number of 32-bit ASNs allocated by the RIRs: 42412 Number of 32-bit ASNs visible in the Routing Table: 34947 Prefixes from 32-bit ASNs in the Routing Table: 174202 Number of bogon 32-bit ASNs visible in the Routing Table:31 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:583 Number of addresses announced to Internet: 3053031936 Equivalent to 181 /8s, 249 /16s and 146 /24s Percentage of available address space announced: 82.5 Percentage of allocated address space announced: 82.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.6 Total number of prefixes smaller than registry allocations: 308731 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 246423 Total APNIC prefixes after maximum aggregation: 70396 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 240152 Unique aggregates announced from the APNIC address blocks:98847 APNIC Region origin ASes present in the Internet Routing Table: 13588 APNIC Prefixes per ASN: 17.67 APNIC Region origin ASes announcing only one prefix: 4016 APNIC Region transit ASes present in the Internet Routing Table: 1797 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 8907 Number of APNIC addresses announced to Internet: 773483392 Equivalent to 46 /8s, 26 /16s and 107 /24s APNIC AS Blocks4608-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-153913 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:271694 Total ARIN prefixes after maximum aggregation: 123742 ARIN Deaggregation factor: 2.20 Prefixes being announced from the ARIN address blocks: 273727 Unique aggregates announced from the ARIN address blocks:130872 ARIN Region origin ASes present in the Internet Routing Table:19086 ARIN Prefixes per ASN:
Re: Dodgy AS327933 ...?
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 someone else's AS in the AS_PATH. To be fair, I have never had to do that, since I've always thought it would be considered bad form. But I suspect that on the simple BGP mechanics of it, no vendor would be able to prevent that in any meaningful way. Then again, path hijacking likely wasn't a thought at the time the Border Gateway Protocol was being conceived. Mark.
Re: Friday Thanks
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 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 there that I'm not in control of. The database maintainers have been mixed in their response so far. This email isn't about name and shame though, I'm not at that point. Instead, I want to provide thanks to two organizations that have been very responsive and easy to deal with in getting records cleaned up. RADb - Thank you. Level3/CenturyLink/Lumen - Thank you. Separately, I know there is some work to do with ARIN's recent RPKI/IRR changes, but as someone from a regional ISP, rather than a national or multi-national ISP, I can say that the tools are moving in the right direction. The experience right now is better than it was several years ago. Thank you ARIN for the improvements and the dedication to work with us on making further improvements. Have a good weekend, Graham
Re: Dodgy AS327933 ...?
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 command completion on the CLI, so this is finger-slip territory, and the two commands are visually similarly enough to each other that it would be easy not to notice. In other news, Mikrotik users at that ASN are discovering that 327,933 prepends may be a bit excessive. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
Re: Friday Thanks
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, but I feel like there shouldn't be competing incorrect information out > there that I'm not in control of. The database maintainers have been mixed > in their response so far. This email isn't about name and shame though, I'm > not at that point. Instead, I want to provide thanks to two organizations > that have been very responsive and easy to deal with in getting records > cleaned up. > > RADb - Thank you. > > Level3/CenturyLink/Lumen - Thank you. > > Separately, I know there is some work to do with ARIN's recent RPKI/IRR > changes, but as someone from a regional ISP, rather than a national or > multi-national ISP, I can say that the tools are moving in the > right direction. The experience right now is better than it was several > years ago. Thank you ARIN for the improvements and the dedication to work > with us on making further improvements. > > Have a good weekend, > I think that’s great to read! Kind regards, Job
Friday Thanks
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 there that I'm not in control of. The database maintainers have been mixed in their response so far. This email isn't about name and shame though, I'm not at that point. Instead, I want to provide thanks to two organizations that have been very responsive and easy to deal with in getting records cleaned up. RADb - Thank you. Level3/CenturyLink/Lumen - Thank you. Separately, I know there is some work to do with ARIN's recent RPKI/IRR changes, but as someone from a regional ISP, rather than a national or multi-national ISP, I can say that the tools are moving in the right direction. The experience right now is better than it was several years ago. Thank you ARIN for the improvements and the dedication to work with us on making further improvements. Have a good weekend, Graham
Re: NTP Sync Issue Across Tata (Europe)
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 is just as secure/insecure as wireless GPS, over which NIST servers can not be reliably accessed. Just as many people who only know wired Internet blindly think wireless channels are secure, you can not recognize various attack modes for the mostly wired internet. These are physical realizations of UTC... that is, a phase-aligned 1PPS pulse and a high precision clock signal. These realizations are used to directly drive the NIST NTP servers at each location. GPS is not involved. UTC??? You are totally wrong. Just as many other people, you are purposelessly seeking meaningless accuracy assuming inertial frame of UTC, which is *NOT* required for correct transactions Because of relativity, we can assume *ANY* inertial frame for simultaneity, which means simultaneity requirement is not so strong. Moreover, information cone allows even less simultaneity for correct transactions. These two timescales are within a few ns of each other, also verified with GNSS common view technology, so one can consider them the same for most purposes. You don't understand simultaneity of theory of relativity at all. 10ns of time difference can not be physically or logically meaningful between locations with 3m distance. Note that a similar process is used to derive UTC(NICT) in Japan. Depending on inertial system, time in US and JP can be different a lot more than 1ms, which means timing error between mainland US and Japan can be a lot more than 1ms. As far as a rubidium clock goes, I'd much rather see it disciplined regularly to a GPS time source, but that comes from the fact that I like my 1PPS to be within a microsecond or so of UTC due to the precision I need in the lab. As I already wrote: : For millisecond accuracy, Rb clocks do not need any synchronization : for centuries. : Rb clocks on GPS are a lot more frequently synchronized, because : a lot more accuracy is required for positioning (10ns of timing : error means 3m of positioning error). you didn't understand the required accuracy for the Internet operators, which is your problem. Note that some of the high end appliances I'm referring to just use GPS over days and weeks to discipline a precision oscillator (sometimes rubidium) which is essentially an automatic calibrating version of what you're proposing. That has nothing to do with the a lot more broad required accuracy required by the theory of special relativity for proper causality. Masataka Ohta
Re: NTP Sync Issue Across Tata (Europe)
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, Colorado campus. In addition, they produce secondary copies of the timescale at Fort Collins and Maryland. The time transfer from Boulder to these locations use various techniques, but not traditional "get your time from GPS" methods. The closest they come is that the Maryland location uses GNSS common view time transfer where the phase difference between the UTC(NIST) realization at each site is measured against the signal from a single GPS satellite that both sites can see in the sky at the same time. The GPS signal is only used as a reference... think start button on a stopwatch. If both sides have the same delay from a specific feature in the GPS signal then you can be sure they are synchronized with each other. This is also just a measurement, and a scientist makes the decision about whether the timescale needs to be adjusted to be kept within specs. These are physical realizations of UTC... that is, a phase-aligned 1PPS pulse and a high precision clock signal. These realizations are used to directly drive the NIST NTP servers at each location. GPS is not involved. Note that this realization of UTC is different than what you get from GPS. GPS gets its time from the naval observatory which has it's own ensemble of clocks which produce UTC(USNO). These two timescales are within a few ns of each other, also verified with GNSS common view technology, so one can consider them the same for most purposes. Note that a similar process is used to derive UTC(NICT) in Japan. Pointing a NTP server at ntp.nict.jp would result in receiving time that was produced independently by NICT, and was not transmitted by GPS. There are various simplifications I've made to the above description so there are a few places the description leaves out intermediate steps. As far as a rubidium clock goes, I'd much rather see it disciplined regularly to a GPS time source, but that comes from the fact that I like my 1PPS to be within a microsecond or so of UTC due to the precision I need in the lab. If I let either of my lab rubidiums free run for more than a few days, I'm typically off UTC by more than that amount.But that level of accuracy isn't typically needed for computer time so I will concede that you could get away with freerunning for an extended period. Not hundreds of years on a rubidium. But a while. Assuming the original calibration was done correctly. Note that some of the high end appliances I'm referring to just use GPS over days and weeks to discipline a precision oscillator (sometimes rubidium) which is essentially an automatic calibrating version of what you're proposing. On Fri, Aug 11, 2023, 3:33 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > 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 public NTP servers 3) Point your clients at the internal NTPd > > servers. > > That is not a very good recommendation. See below. > > > At some point, using publicly available NTP sources is redundant > > unless one wants to mitigate away the risks behind failure of the GPS > > system itself. > > Your assumption that public NTP servers were not GPS-derived NTP > servers is just wrong. > > > What I'm advocating against is the seemingly common practice to go > > buy an off-the-shelf lower-cost GPS-NTP appliance (under $1K or so), > > stick an antenna in a window or maybe on the rooftop, and point all > > your devices at that device. > > Relying on a local expensive GPS appliance does not improve > security so much and is the worst thing to do. > > But, additionally relying on remote servers (including those > provided by NIST) is subject to DOS attacks. > > As such, the ultimate (a little expensive) solution is to have > your own Rb clocks locally. > > Masataka Ohta > >
Re: Dodgy AS327933 ...?
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. 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. Nick
Re: Dodgy AS327933 ...?
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 does command completion on the CLI, so this is finger-slip territory, and the two commands are visually similarly enough to each other that it would be easy not to notice. It is not terribly clever of Mikrotik to have two commands that do different things be that close in syntax. 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. Mark.
Re: NTP Sync Issue Across Tata (Europe)
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 public NTP servers 3) Point your clients at the internal NTPd servers. That is not a very good recommendation. See below. At some point, using publicly available NTP sources is redundant unless one wants to mitigate away the risks behind failure of the GPS system itself. Your assumption that public NTP servers were not GPS-derived NTP servers is just wrong. What I'm advocating against is the seemingly common practice to go buy an off-the-shelf lower-cost GPS-NTP appliance (under $1K or so), stick an antenna in a window or maybe on the rooftop, and point all your devices at that device. Relying on a local expensive GPS appliance does not improve security so much and is the worst thing to do. But, additionally relying on remote servers (including those provided by NIST) is subject to DOS attacks. As such, the ultimate (a little expensive) solution is to have your own Rb clocks locally. Masataka Ohta
Re: Dodgy AS327933 ...?
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 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 command completion on the CLI, so this is finger-slip territory, and the two commands are visually similarly enough to each other that it would be easy not to notice. Nick
Re: Dodgy AS327933 ...?
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 what should be a prepend becoming an AS_PATH? Genuine question - I have zero experience with Mikrotik in an SP role. Mark.
Re: Dodgy AS327933 ...?
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". https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters Nick
Re: Dodgy AS327933 ...?
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 vendors went from explicitly defining the AS multiple times to determine the number of prepends, to, this :-)? Mark.
Re: Dodgy AS327933 ...?
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: nanog@nanog.org Subject: Re: Dodgy AS327933 ...? Date: Thu, 10 Aug 2023 09:24:32 -0400 AS2 is the most hijacked prefix in the world. Yes UD still owns it, but since different router vendors use different methods of prepending AS numbers, many folks try to prepend twice and end up announcing on AS2.. thanks mike On 8/10/23 9:02 AM, Mark Tinka wrote: > > > On 8/10/23 11:38, Frank Habicht wrote: > > > > > from a 2019 DB snapshot: > > > > aut-num: AS327933 > > as-name: GROUPE-TELECOM-SPRL > > descr: GROUPE TELECOM SPRL > > status: ASSIGNED > > org: ORG-GTS2-AFRINIC > > admin-c: YM8-AFRINIC > > tech-c: YM9-AFRINIC > > notify: ***@gtl-rdcongo.com > > mnt-lower: GTS2-MNT > > mnt-routes: GTS2-MNT > > mnt-by: AFRINIC-HM-MNT > > changed: ***@afrinic.net 20150917 > > source: AFRINIC > > > > I think the most common way to get out of this DB is to not pay something. > > > > I'd guess that > > > > aut-num: AS37451 > > as-name: CongoTelecom > > descr: CONGO TELECOM > > > > has a relationship with them and AS327933 wanted to prepend 2x [1] to their > > sole provider. (AS37451) > > We are seeing some weird routing from them, and the AS2 they are attached to > (University of Delaware) seems odd. > > Not sure if any of the American folk on this list can verify AS2 is really > part of the University of Delaware... > > Mark. -- Mike Davis Lead Network Architect University of Delaware - 302.831.8756 Newark, DE 19716Email da...@udel.edu
