Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#1510 closed enhancement (fixed)

Implement a RouterInfo parameter similar to Tor's MyFamily

Reported by: str4d Owned by: zzz
Priority: minor Milestone: 0.9.24
Component: router/netdb Version: 0.9.18
Keywords: peer-selection privacy anonymity Cc:
Parent Tickets:


Tor has the MyFamily option that operators can set to group their nodes in the consensus, which helps their clients to build circuits through distinct operator groups. But there is no consensus on whether it is beneficial, and the current implementation has an O(n2) space requirement (because every node's descriptor lists every other node in the family).

They have an open ticket for removing the MyFamily option for various reasons, but also a proposal for a better implementation if the general idea is decided to be sound.

I am curious as to how beneficial (or otherwise) this would be for I2P. It would only affect usage of peers whose operators choose to configure the setting; for all other peers, the peer selection algorithm would be unchanged.

Open questions:

  • How would this affect the probability of selecting malicious peers for a tunnel (who would not use the setting honestly)?
  • What happens if a router only knows peers that are all in the same family? Unlikely, but a possible corner case.

If we did decide this to be a good idea, it would be implemented along the lines of Tor's newer proposal.


Change History (13)

comment:1 Changed 4 years ago by zzz

  • Owner zzz deleted
  • Status changed from new to assigned

Sounds like more trouble than it's worth, even if all the uncertainties were resolved. Any feature that requires non-default configuration has a low payoff.

And if we do make it easy for users to stuff arbitrary text into their RI for all to see, it won't be long before trouble ensues.

We already have the /16 check which covers a lot of these issues automatically.

Not in favor.

comment:2 Changed 3 years ago by zzz

  • Milestone changed from undecided to 0.9.25
  • Status changed from assigned to open

After writing the Sybil analysis tool, I now think this is a good idea.

I count at least 13 floodfills that have a common /24 with another, including two pairs with the same IP. Most of them I think I i know who runs them, but not all.

Simply trusting a floodfill more if it has a family name set probably isn't that helpful, but it's useful for quick analysis. The proposal for a family signature in tor 242 linked above is adaptable to our setup but a lot more work. We could start with just the name as set in advanced config, and add the sig stuff later.

comment:3 Changed 3 years ago by zzz

We would bundle the family pubkey certs as we do with other certs, but use Ed instead of RSA. We'd probably only need to sign the family name and the router hash, not anything that changed every time, so we'd only have to sign it once, not every time we published our RI. We'd only need to do sig verification in the Sybil checker.

comment:4 Changed 3 years ago by zzz

... unless we want to enforce "nodes can't be put in families without their consent"

comment:5 Changed 3 years ago by zzz

We'd have to use EC keys, not Ed, for this.

There's a number of things to implement before we can store and distribute Ed pub/priv keys:

  • EdDSAPrivateKey and EdDSAPublicKey don't have getEncoded() implemented (for PKCS#8 and X.509 respectively). We don't have a real ASN.1 lib so we'd have to do it by hand, going off of the code we have in SigUtil?. Have to find the standard OID and parameter stuff.
  • We would need decoding methods as well
  • Java keystore doesn't know about Ed, so we couldn't store our privkeys in there, we'd have to store natively in PKCS#8
  • All this would be a pita.

comment:6 Changed 3 years ago by zzz

  • Owner set to zzz
  • Status changed from open to accepted

To elaborate on the proposal in comment 5 above:

  • new netdb properties would be family=foo and family.sig=b64signature
  • sign/verify algorithm would be the signature of the concatenation of (family name in UTF-8, 32-byte binary router hash). This doesn't change per-publish, so the router would only have to generate it once. Verifying routers could cache the verification result.
  • to set up, set the family name in the router advanced config with
  • first router in the family would generate keypair. Distribute privkey to other family members and install before setting the family. Check in pubkey cert to certificates/family. Alternative: Publish pubkey in the RI also. Router would have to store these persistently. First key for a family name wins. Maybe we implement both, so that some names are effectively reserved by having a cert for them.
  • This prevents any unauthorized routers from joining an existing family.


  • I've added code to publish the family name, and my floodfills are running that code with the family 'i2p-dev'.
  • just did some x.509 certificate utility cleanup that I needed and checked that in
  • I have some untested, un-checkedin code to do signing/verification.

Would appreciate comments from str4d and others on whether we really want to do this. Still just playing around with it.

comment:7 Changed 3 years ago by zzz

Initial sign/verify impl in 497829569ca0cf378e5cca9861e3e0187af531a5 0.9.23-11
Sign/publish hooked in and used, verify not yet hooked in, and nothing in peer selection yet.

comment:8 Changed 3 years ago by zzz

I have 3 routers out there running this with the family "i2p-dev".

Instructions for first router in family;

  • set adv. config.
  • restart
  • verify your router info has a family.sig entry

Instructions for other routers in family;

  • copy adv. config.,, from first router
  • copy ~/.i2p/keystore/family-example.ks from first router to same place
  • copy ~/.i2p/certificates/family/example.crt from first router to $I2P/certificates/family/example.crt
  • restart
  • verify your router info has a family.sig entry

I will be making an enhancement so the cert doesn't have to be copied.

comment:9 Changed 3 years ago by zzz

Enhancement in comment 8 to use our local cert to verify our own family is in 0.9.23-12.

Enhancement / alternative in 4th bullet of comment 6 (publishing pubkey) implemented in bf18831e5b7e3a25f1a9012ae603e3ea61836961 to be 0.9.23-13. This allows all families to be verifed without a local cert. Local certs are still supported and if present are used in preference to the published pubkey. When we have the cert, it can't be spoofed.

comment:10 Changed 3 years ago by zzz

Same-tunnel family checking in 0c91ed8c49e2924329b367f5f74e253fe5a33db1 to be 0.9.23-15

This does not check family sigs and I'm still unsure if we should. Sigs are currently checked in KNDF validate() but we neither act on nor store the result.

Reviewing Tor 242 for what may be left to do, they allow for multiple family membership, I can't think of any good reason to add that complication.

Reading Tor tkt 6676, the problems are ease and incentives for configuring. I definitely haven't solved that. For ease of use we will need a new /configfamily page. Incentives? dunno.

comment:11 Changed 3 years ago by zzz

  • Milestone changed from 0.9.25 to 0.9.24

Hearing no objections so far, added preliminary spec to http://i2p-projekt.i2p/en/docs/how/network-database near the top. This may also help in review of the key and sig format and sign/verify algorithm.

Any /configfamily UI would be in 0.9.25 or later.

Interesting data from Phillip Winter on Tor: "As of Nov. 2015, there are approximately 350 families in the network whose size ranges from only two to 20 relays."

comment:12 Changed 3 years ago by zzz

  • Resolution set to fixed
  • Status changed from accepted to closed

<str4d> zzz2, re: MyFamily?, see - I need to figure out what Tor is doing and for what reasons
<str4d> No point putting something in that we will later regret
<zzz2> yeah i've seen that. but see ML for recent onionoo changes
<zzz2> seems like they are moving forward with something
<zzz2> they have 350 families in current net
<dg> it's thought that only the good guys will specify MyFamily? so you're more likely to end up with an attacker
<dg> that was the thinking the last time I looked into it, i think it was only a minor part of a sybil paper
<dg> tor have been meaning to kill it for a long time
<zzz2> looks to me like they're going forward with fixing it
<zzz2> if we're going to start serious sybil monitoring, then knowing who the good guys are is important too
<str4d> Thing is, what we currently do as "MyFamily?" isn't quite what Tor does
<str4d> And I'm still getting my head around its implications
<zzz2> right. it's closer to what they're going to do
<zzz2> winter reports 18 sybil attacks in last 5 1/2 years

latest tor activity:
"family" has become "alleged_family" and "indirect_family". These are Onionoo properties and the replacements have more versatility? This is not a removal of the Tor family feature.

Persistent objection is that 'only good guys will use family'. However, knowing who the good guys are is extremely valuable when doing Sybil analysis.

The one feature not provided by my implementation is membership in multiple families. My assessment was that it's a needless complication and I couldn't think of a use case.

Pushed my i2p-dev family cert in 0.9.23-23-rc, and that's it for 0.9.23. We can rip it out or redo it in some future release if we want to, but my general proposal has been here for 6 weeks and the code checked in for 5 weeks, without any objection seen, so I consider it done for now.

comment:13 Changed 3 years ago by zzz

Config UI including key export/import in c2aed23bc62c85a7c1d224218032a637200b2d85 i2p.i2p.zzz.test2 to be propped for 0.9.25

Note: See TracTickets for help on using tickets.