[tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?

Virgil Griffith i at virgil.gr
Fri Feb 5 10:28:43 UTC 2016


I withdraw my desire this proposal.  In Roster we wouldn't want these /16
network families---we just wanted to collapse some relays together when we
reliably believe they have the same operator, and there's no reason to
believe the majority of relays within a /16 are owned by the same person.

Ergo, Roster will forgo this kind of merging.

-V

On Friday, 5 February 2016, Karsten Loesing <karsten at torproject.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [Removing metrics-team@ to avoid cross posting.]
>
> On 28/01/16 21:22, Tim Wilson-Brown - teor wrote:
> >
> >> On 29 Jan 2016, at 07:20, Roman Mamedov <rm at romanrm.net <javascript:;>>
> wrote:
> >>
> >> On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor
> >> <teor2345 at gmail.com <javascript:;>> wrote:
> >>
> >>> Tor already considers relays in the same IPv4 /16 to be in the
> >>> same family.
> >>
> >> Maybe a step further in this would be to autoextend manually
> >> declared families with all relays running on the same IPs of any
> >> relays in the family. Dunno how complex or how useful this would
> >> be. It could at least fix-up some outdated or missed
> >> declarations.
> >
> > In Tor, or OnionOO?
> >
> > Tor already does this using the IP address whenever a path is
> > built. If Tor added it on the relay side, then we'd bloat
> > descriptors for no reason.
>
> Agreed.
>
> > If OnionOO added it, it would save OnionOO clients some work.
>
> Let's consider this.  I'm pasting current definitions of related
> Onionoo fields here, so that people can follow more easily:
>
>  - "effective_family": Array of $-prefixed fingerprints of relays that
> are in an effective, mutual family relationship with this relay. These
> relays are part of this relay's family and they consider this relay to
> be part of their family. Omitted if empty or if descriptor containing
> this information cannot be found.
>
>  - "alleged_family": Array of $-prefixed fingerprints of relays that
> are not in an effective, mutual family relationship with this relay.
> These relays are part of this relay's family but they don't consider
> this relay to be part of their family. Omitted if empty or if
> descriptor containing this information cannot be found.
>
>  - "indirect_family": Array of $-prefixed fingerprints of relays that
> are not in an effective, mutual family relationship with this relay
> but that can be reached by following effective, mutual family
> relationships starting at this relay. Omitted if empty or if
> descriptor containing this information cannot be found.
>
> Now, from reading this thread I can see us adding or extending the
> following fields:
>
>  - Extend "effective_family" to also include relays on the same IP
> address or in the same /16.  I'd rather not want to do this, because
> we wouldn't be able to say whether that other relay is in a mutually
> declared family relationship or just runs on a nearby IP address.
>
>  - Add new "network_family" field with fingerprints of all relays in
> the same /16.  Plausible, but duplicates fingerprints that are already
> in "effective_family".
>
>  - Add new "network_family" field with only those fingerprints of
> relays in the same /16 that are not contained in "effective_family".
> "Tor considers these relays to be part of your relay's family, because
> they have similar enough network addresses.  If you are running them,
> please consider setting the family option."  Plausible, though not
> trivial to grasp without further explanation.
>
>  - Add new "extended_network_family" field with fingerprints of relays
> in the same /16 as this relay or relays in "effective_family" and
> "indirect_family", except for fingerprints in those two fields.  Also
> plausible for the Roster use case to identify all relays close to the
> family that the user may have omitted in their family definitions.
> Not sure if this is necessary.
>
>  - Add new "abandoned_family" field with fingerprints of relays that
> declare this relay to be part of their family but that are not
> contained in this relay's family declaration.  Looks like we never
> considered this field before, but it might be useful to help relay
> operators fix their family declarations.
>
> Which of these fields would be useful to have?  "All of them" is not a
> good response, because we shouldn't make Onionoo responses bigger if
> nobody uses the new data.  But I'm happy to discuss use cases and then
> add new fields as required.
>
> All the best,
> Karsten
>
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJWtGubAAoJEJD5dJfVqbCrwDEIAMN/JCYq99J/H3AZKqkt3pLe
> qvWP8uQxBfbnmxwOhOq4IFFCa1o+FpITOxmhZEuxVNGaqszBqSxFpDn62pjK8YCS
> 7Wi2IqUoZDIdHwLsJMgfrn+/HH4BoctTu0PzHWsZsmcdjJqPr8R+AP7WRZN3SM2W
> /ML8AULWIwSUVmIfKD3iYM9RbFfxFeCARirDsAxC394z2ei06git4sJA5cSROx35
> 9IzqdpPyJoplYBRk7INCmr0bHNXvsIRODQ0n0QIJrIl1ESHpqhsy13fTo/1ndlKR
> BUM2XCao0HABwpdBOrinfpybuGUSPXjrqw8expkUE+w2VuzOdkkNod1J3wgFyXc=
> =KM0S
> -----END PGP SIGNATURE-----
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org <javascript:;>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160205/52ad0df9/attachment-0001.html>


More information about the tor-relays mailing list