RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Adam Thompson <athompson () merlin mb ca>]

I partially agree with you, but… 10 is way too aggressive.  I’m already seeing a “true” internet diameter of up to 13 
AS hops today.  Here’s the data I’m using to form that opinion.

[ NOTE: my tooling didn’t handle BGP confederations in the RIB dump properly.  It’s sufficiently rare (only 1009 routes 
in total) that I’m not going back to square one to compensate for that, the data’s not noticeably skewed because of it, 
with one exception: the len=15 and len=16 entries in the de-prepended tale are both bogus.  I left them in in the 
spirit of full disclosure. ]

This is the AS path-length distribution in my RIB as of a few minutes ago.  Like everyone else, I do some moderately 
strange things for <reasons> including artificially locally prepending routes from some of my upstreams, so I’m quite 
certain no-one else’s will exactly match mine.  The overall shape of the distribution, though, should be very similar, 
probably with the peak shifted left or right slightly.

Pathlen
Count
1
1864
2
77314
3
223030
4
248878
5
729240
6
627685
7
224092
8
105225
9
60962
10
50201
11
22856
12
11914
13
7224
14
5423
15
4421
16
2756
17
1577
18
945
19
422
20
669
21
477
22
116
23
70
24
75
25
163
26
33
27
40
28
5
29
41
30
5
31
5
33
1
35
12
38
5
39
2
40
1
55
1

I took a look at some of the outliers, and they are, in the extreme cases, somewhat insane, with over 20 prepends or 
more in those last few cases.  However, at least a few of the pathlen>=20 entries could be legit.  Could be.  Not 
saying they are, just that there are some paths that aren’t immediately obvious BS and it would take a lot more time & 
effort to figure that out.

I then eliminated ALL the prepends, remote, and local and transit, and that length distribution changes to look like 
this, which should reflect the “true” diameter of the internet as seen from here:

Pathlen
Count
1
18950
2
223149
3
563843
4
824648
5
532985
6
165056
7
47559
8
16759
9
8430
10
3746
11
519
12
233
13
6
15
1
16
2
(Interestingly, the shape of the distribution doesn’t change significantly.  That hints that most people could be doing 
prepending in roughly the same way.)

Using your suggestion of as AS-PATH length of 10 as a cutoff, you’d be dropping ~4.5% (109,460 routes here) of the 
total RIB.  But even in my artificially de-prepended dataset, I still see 4,507 presumably-legitimate routes with a 
path length >= 10.

I’m not saying a threshold is a bad idea.  (I’m on the fence.)  I AM saying that using 10 as your cutoff point is too 
aggressive, and in my opinion, way too aggressive.
Based on the de-prepended dataset, the approximate diameter of my internet (not necessarily yours) is 13 AS hops.  (Not 
15 or 16, see note above.)

Since it’s entirely public data, here’s the raw paths from me to AS 270606, prepends and all, that generated my “true” 
diameter of 13, as recorded in my looking glass:

  *   I* N 177.37.16.0/22 206.211.216.51 100 0 7122 7122 577 6461 52320 53087 262740 262740 262740 262740 262740 262740 
266097 268868 61568 26615 10429 263144 270606
  *   I* N 177.37.16.0/22 206.211.216.52 100 0 7122 7122 577 6461 52320 53087 262740 262740 262740 262740 262740 262740 
266097 268868 61568 26615 10429 263144 270606
  *   I* N 177.37.16.0/22 216.73.71.131 100 0 6327 6327 6327 6461 52320 53087 262740 262740 262740 262740 262740 262740 
266097 268868 61568 26615 10429 263144 270606
(Formatting didn’t translate well… the locally-prepended AS path for these 3 examples starts with 7122 7122 577, or 
6327 6327 6327.)

I do not have any alternate path to those prefixes in my RIB.  The deduped 13-long path is “7122 577 6461 52320 53087 
262740 266097 268868 61568 26615 10429 263144 270606”.

Do I really care if education users in Manitoba can reach R3 Telecom users in Brazil?  Probably not (although there are 
quite a lot of Brazilian international students here, so maybe?) but this demonstrates that the “diameter of the 
internet” is absolutely not well under 10.

I’ll point out, since I speculated about this in a previous email, the most extreme case discussed here was purely on 
commercial internet, and did not involve NREN paths at all.  I went looking for NREN-style prepending and found several 
examples buried in the middle of the distribution.  That presumptive root cause doesn’t appear, at least at first 
glance, to contribute much to the extreme path lengths I see.

Imposing a limit like this has a strong precedent: Sprint(?)’s cap at accepting only /24 and larger, waaaaaay back.  
Like that action, this max-path-len proposal is likely to be discriminatory because it implicitly favours ASNs located 
in areas with good connectivity to the “core”, i.e. mainly the eastern US and some areas of western Europe.  (I also 
did not examine the entire path to AS270606 for sanity – it’s not always about simple availability, sometimes perverse 
incentives play a strong role, too.)
If I start looking at the 233 routes of “true” distance 12, where will they be located?  Or the 519 at 11?  Remember, 
those are already the de-prepended paths.  I don’t want to have to police the RIB that tightly, deciding which routes I 
will and won’t accept and adjusting the limit periodically.

Unless your intent is to eliminate prepend-based traffic engineering from the internet altogether, which case 10 is a 
perfectly reasonable choice, but in the absence of any other globally-usable tool/knob, that’s a hill I WILL die on.

If there’s broad consensus that a path length limit is a good thing, I would suggest a value of no less than 32, based 
on the data I’ve got in my RIB right now.  I think, based only on random sampling of longer AS paths in my RIB, that 32 
would still give operators the latitude to perform AS-path-based traffic engineering at origin, during transit, and 
locally upon receipt, without routes getting inexplicably blackholed anywhere.

I’ve heard tonight that a path length limit of 32 is already commonly implemented.  Regardless of whether I think 
that’s a good idea, the spectre of the stack-breakingly-long path seems to be already mitigated in many places, but 
perhaps not widely?

To sum up, Tom’s conclusions as expressed in his email (below) may be qualitatively correct, but they are 
quantitatively wrong, at least on the matter of the numeric threshold.  And… I don’t really want to be the next 
Sprint(?) in BGP history just to protect myself from newbies on Mikrotiks[1], do you?

-Adam


[1] and others, yes, I know it’s not purely a Mikrotik issue.


Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson () merlin mb ca<mailto:athompson () merlin mb ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: Tom Beecher <beecher () beecher cc>
Sent: Saturday, March 26, 2022 11:35 AM
To: Adam Thompson <athompson () merlin mb ca>
Cc: Paschal Masha <paschal.masha () ke wananchi com>; nanog <nanog () nanog org>
Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the DFZ, my mistake.)

Essentially, if ASN X is announcing a prefix with an excessive number of prepends, they are saying to the world 'This 
path exists , but it is hot garbage.' I'm more than happy to oblige those instructions and just drop that announcement 
completely. If ASN X announces that prefix with a reasonable number of prepends, happy to take it and use it.

If I get a prefix with an as-path longer than 10, (regardless of the state of prepends), I interpret that as :

1. They have made a mistake.
2. Someone else made a mistake.
3. They think that's a good idea, and have some things yet to learn. ( The old clue by four as Matt put it.)
4. It's malicious.
5. They actually are somehow more than 10 ASNs away from me. ( I don't even know if this is possible anymore without 
extreme effort. )

In any of those scenarios , I don't really care about optimized routing to that destination. Perfectly happy to just 
follow 0/0 to a DFZ upstream and let it go how it's going to go, or not. If there is a traffic impact such that an 
exception HAS to be made, that can be addressed as needed, but I can't think of a single circumstance I have hit where 
the correction involved accepting an obnoxiously long as_path announcement. ( I don't mean to imply none exist ; I'm 
sure someone has had to work though that. )

Maybe a length of 10 doesn't work for some environments and use cases, but I still am a firm believer that at a certain 
point, there is a length that becomes straight 'really don't care'.  I'd rather not discover a BGP implementation 
problem or acid trip memory pointer party by accepting announcements that are useless.







On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson <athompson () merlin mb ca<mailto:athompson () merlin mb ca>> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long paths are not uncommon in this scenario, in 
order to do traffic steering.  If there’s another solution that affects global inbound traffic distributions, I’d love 
to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as a better path was already known by at 
least one edge router, that might be workable, but you’d have to keep track of it somewhere to reinstall it if the 
primary route went away… at which point you may as well have not dropped it in the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson () merlin mb ca<mailto:athompson () merlin mb ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG <nanog-bounces+athompson=merlin.mb.ca () nanog org<mailto:merlin.mb.ca () nanog org>> On Behalf Of Tom 
Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha <paschal.masha () ke wananchi com<mailto:paschal.masha () ke wananchi com>>
Cc: nanog <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN prepending 255 times

The best practice with regards to as_path length is to have an edge filter that dumps any prefix with a length longer 
than say 10. Depending on the situation, might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just shoot it and ride the 0/0 train.

On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <paschal.masha () ke wananchi com<mailto:paschal.masha () ke wananchi 
com>> wrote:
:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Regards
Paschal Masha | Engineering
Skype ID: paschal.masha

----- Original Message -----
From: "Erik Sundberg" <ESundberg () nitelusa com<mailto:ESundberg () nitelusa com>>
To: "nanog" <nanog () nanog org<mailto:nanog () nanog org>>
Sent: Friday, March 25, 2022 6:43:38 AM
Subject: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN prepending 255 times

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24<http://46.42.196.0/24> 
from 255 prepends to a more reasonable number of prepends let's say 20. Thanks!

This is a Kazakhstan register IP Block and ASN



Network Next Hop Metric LocPrf Weight Path

*> 46.42.196.0/24<http://46.42.196.0/24> x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i








CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it 
may contain confidential information that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, 
distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If 
you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must 
destroy the original transmission and its attachments without reading or saving in any manner.
Thank you.