DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

• Previous message (by thread): DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
• Next message (by thread): WP: Russian military behind hack of satellite communication devices
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: Tom Beecher <beecher at beecher.cc>
Sent: Saturday, March 26, 2022 11:35 AM
To: Adam Thompson <athompson at merlin.mb.ca>
Cc: Paschal Masha <paschal.masha at ke.wananchi.com>; nanog <nanog at 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 at merlin.mb.ca<mailto:athompson at 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 at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org<mailto:merlin.mb.ca at nanog.org>> On Behalf Of Tom Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha <paschal.masha at ke.wananchi.com<mailto:paschal.masha at ke.wananchi.com>>
Cc: nanog <nanog at nanog.org<mailto:nanog at 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 at ke.wananchi.com<mailto:paschal.masha at 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 at nitelusa.com<mailto:ESundberg at nitelusa.com>>
To: "nanog" <nanog at nanog.org<mailto:nanog at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220330/43df0fea/attachment.html>

• Previous message (by thread): DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
• Next message (by thread): WP: Russian military behind hack of satellite communication devices
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]