Config option to disable dialing specific subnets entirely

[jbenet]

See #1226

Having a config option to disable dialing local subnets entirely. maybe even allowing configurable address filters.

We need to:

• come up with a config format for the filters
• add a config option for the subnet filters
• add subnet filter support to p2p/net

This will make it possible to both (a) prevent dialing local subnets entirely, and (b) prevent dialing everything BUT local subnets (i.e. don't connect to WAN).

One open question about these filters is:

• whether to filter all traffic (dials + listens), just dials, or make it configurable by subnet.

[jbenet]

possible config format:

{ // ...
 "Swarm": {
  "TrafficFilters": [
    { "0.0.0.0/0": "deny"},
    { "10.10.10.0/28": "allow"},
  ]
}}

meanig that no config is as if:

{ "Swarm": {
  "TrafficFilters": [
    { "0.0.0.0/0": "allow"},
  ]
}}

People more experienced with traffic forming tools should comment here and tell me all the desires. we can probably implement something pretty expressive without too much more effort.

[timgws]

What about if we had something like Apache's htaccess1 format?

  DefaultOrder deny,allow
  Deny from 10.0.0.0/8
  Allow from all

It's expressive and short. For example, a machine only wanting connections to machines on the same LAN network could do:

  DefaultOrder deny,allow
  Deny from all
  Allow from 10.0.0.0/8

[jbenet]

Ah yeah that's promising! maybe we can discuss iptables or nft formats too, and pick whatever is best for us. anyone experienced with those want to throw out some relevant examples?

[timgws]

iptables would be similar, but it's a little "unfriendly". If you want world domination, you want something that with a limited amount networking knowledge, know exactly what you are doing within seconds of staring at the file.

With iptables you can block an IP like this:

 iptables -I INPUT -s 1.2.3.4 -j DROP

-I inserts this rule into a chain (in this case, INPUT). -s specifies the source address (this can also be a netblock, such as 192.168.0.0/23). -j specifies a chain to jump to (here it's DROP).

Would we maybe want to have configuration for each interface as a possibility? Maybe this is something best left to the operating system to work out?

[whyrusleeping]

I'm wondering if this should be implemented in the peerstore, since thats where we handle addresses. Maybe when we ask if for addresses to dial, it can filter them by our blocklist, but when we ask it for addresses to send to other peers, it can give us all of them. (doing it this way also makes the changes to the construction process a little simpler)

[timgws]

That sounds like the right place to do it.

The only question is what about the swarm connect command? Do we have an option to force a connection to a given IP address given by the user, even if the IP address has been denied with a block list?

[whyrusleeping]

@timgws yeah, that seems like the right thing to do, have a -f option to ignore the blacklist

[whyrusleeping]

@jbenet i'm now wondering if these should be specified in some sort of multiaddr format like: /filter/ip4/192.168.0.0/16 or something

[jbenet]

@whyrusleeping oh interesting! that might work very well.

we should probably note that it's a cidr subnet address, with a prefix too:

/filter/cidr/ip4/192.168.0.0/16

# which means

/filter
+-- /cidr/
    +-- /ip4/192.168.0.0
     /16

though this o/ gets clunky, because the address /cidr/<ip-addr>/<length> now has a sub-multiaddr. maybe it makes sense to flip it:

/filter/cidr/16/ip4/192.168.0.0/

# which means

/filter
+-- /cidr/16
    +-- /ip4/192.168.0.0

but that gets farther away from the <ip>/<length> cidr convention.

(formats are hard.)

[whyrusleeping]

yeah, that could work. do we wanna make a decision on what the proper 'filter format' should be for multiaddr before i start hacking?

[jbenet]

1. instead of "filter" which is generic and liable to clash, i'd go for something like /ip-subnet

2. i'm thinking that this part is not needed, if this address is in a field like:

   Filters: [
     "/ipcidr/16/ip4/192.168.0.0"
     "/ipcidr/16/ip4/192.168.0.0"
   ]
   

3. i'm not super comfortable with switching the order, but not sure what else to do there. shrug

---

let's go with either:

/ipcidr/16/ip4/192.168.0.0
/ip4/192.168.0.0/ipcidr/16

[whyrusleeping]

i like the latter

[jbenet]

i like the latter

let's do it

[whyrusleeping]

alright, should i call the package multiaddr-filter? multiaddr-ipmask?

[jbenet]

both sgtm