Skip to content
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

Open
shyrwall opened this issue Dec 7, 2020 · 17 comments
Open

Per-AS connection limit #7090

shyrwall opened this issue Dec 7, 2020 · 17 comments

Comments

@shyrwall
Copy link

shyrwall commented Dec 7, 2020

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.

@moneromooo-monero
Copy link
Collaborator

Yes. Patches welcome.

@shyrwall
Copy link
Author

shyrwall commented Dec 7, 2020

Why did i know you were going to answer like this :D ok. Patch incoming.

@selsta
Copy link
Collaborator

selsta commented Dec 7, 2020

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 --ban-list /path/to/block, v0.17.1.6 also has some improvements against them.

Per-AS connection limit would still be nice in the future.

@shyrwall
Copy link
Author

shyrwall commented Dec 7, 2020

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 --ban-list /path/to/block, v0.17.1.6 also has some improvements against them.

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.

@moneromooo-monero
Copy link
Collaborator

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).

@shyrwall
Copy link
Author

shyrwall commented Dec 7, 2020

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.

@vtnerd
Copy link
Contributor

vtnerd commented Dec 7, 2020

@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.

@shyrwall
Copy link
Author

shyrwall commented Dec 7, 2020

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.

@moneromooo-monero
Copy link
Collaborator

Any chance you might have started looking at this yet ? :)

@moneromooo-monero
Copy link
Collaborator

pingy pingitty ping, that would be a really nice patch ^_^

@shyrwall
Copy link
Author

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

@moneromooo-monero
Copy link
Collaborator

Ah. Well, I'm C++ literate but BGP illiterate :D Is the bitcoin core code under a suitable licence as a first prerequisite ?

@jonathancross
Copy link
Contributor

Friendly ping @shyrwall

@shyrwall
Copy link
Author

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 :)

@moneromooo-monero
Copy link
Collaborator

I think if you can get me a data structure with information on what it means, I can do the rest.

@shyrwall
Copy link
Author

I assume your C-eyes can see the structure from,

https://github.com/bitcoin/bitcoin/blob/master/src/util/asmap.cpp
bitcoin/bitcoin@ec45646
https://github.com/sipa/bitcoin/blob/202004_asmap_tool/src/bitcoin-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 .
Resulting file is currently about 1.1MB.

@plowsof
Copy link
Contributor

plowsof commented Sep 2, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants