-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-AS connection limit #7090
Comments
Yes. Patches welcome. |
Why did i know you were going to answer like this :D ok. Patch incoming. |
FYI, there is a list of known malicious peers, mostly hosted on OVH: https://gui.xmr.pm/files/block.txt You can apply the list as a ban list using Per-AS connection limit would still be nice in the future. |
I just blocked all ovh. But it's still a bad workaround. Will send a asn-limit patch soon. |
Note that there's currently a preference for peers not in the same /16 range. It would be nice to use the system, so you end up still connecting to the same AS if there are no other peers (ie, testing). |
That would only occur in testnet? Since 1 peer per AS should be enough in normal scenarios. Bitcoins /16 limit (i assume monero inherited) was flawed from the beginning. Most likely it was used since it required no external sources to separete isps. But it's bad to use it today. |
@shyrwall what is the technique you plan to use? This isn't as trivial as /16 lookup because it should require some external database. This is primarily why I stopped cold after looking into it - I wasn't sure how someone could independently verify the information. The experimental Bitcoin Core method is even worse with regards to verification. They are trying to identify every AS that a connection flows through to select peers. It helps with eclipse and mitm attacks, but its based on this database of routing information that some external authority publishes. |
2 solutions. One is to dump the prefixes from the RIR dbs. Or to dump from the real bgp table. I will do the last since its reality. Ofc this means it will have to be updated regularly but thats a non issue since it will be so much better than a dumb /16 drop. |
Any chance you might have started looking at this yet ? :) |
pingy pingitty ping, that would be a really nice patch ^_^ |
Hi Sorry. Just came back from NY holiday. I'll try to have time to look at it again. I just plan on trying to copy Bitcoin Cores code since they have a good ""compression"" algo for the as table. But keep in mind i'm CPP illiterate. Someone else can probably knock this out in a few hours :P |
Ah. Well, I'm C++ literate but BGP illiterate :D Is the bitcoin core code under a suitable licence as a first prerequisite ? |
Friendly ping @shyrwall |
I discussed it with moneromoo on irc. I can assist with the part of getting the AS,IP data since i'm a networking guy but learning the code would take too much time since i suck at C :) |
I think if you can get me a data structure with information on what it means, I can do the rest. |
I assume your C-eyes can see the structure from, https://github.com/bitcoin/bitcoin/blob/master/src/util/asmap.cpp The best way to generate the file I guess can be discussed later. I got an example at https://github.com/shyrwall/asmap . |
A bounty for this issue has been created by ydvim (currently at 1.21 XMR) https://bounties.monero.social/posts/93 PR that needs review / closes this issue #7935 |
When spinning up my monerod I get these 26 connections split between inc/out.
OVH - 22
Suddenlink - 1
Digitalocean - 1
Centurylink - 1
Contabo - 1
This is very disconcerting for me. 85% of nodes on my newly spun up monerod is behind OVH.
For all I know it's all run by the same entity. One can also assume that there's a high probably of there being
hundreds of nodes behind OVH if I randomly got 22 instantly.
Has there been any thoughts of implementing the same per-AS limit that now exists in Bitcoin Core?
Even if I don't think many node operators are using it it's a good way of spreading connections among ISPs in a world where
I can spin up a vps with 100 ips for like $25. And it would be really easy to implement.
The text was updated successfully, but these errors were encountered: