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

[Karsten Loesing]

-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  wrote:
>> 
>> On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor
>>  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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Virgil Griffith]

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  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 >
> wrote:
> >>
> >> On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor
> >> > 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 

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

[Tim Wilson-Brown - teor]

> On 5 Feb 2016, at 21:28, Virgil Griffith  wrote:
> 
> 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.

There are known cases where relays on the same IP address happen to be using 
the same provider and external NAT, but have different operators.

> 
> Ergo, Roster will forgo this kind of merging.
> 
> -V
> 
> On Friday, 5 February 2016, Karsten Loesing  > 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  >
>> wrote:
 
 On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor
  > 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 

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

[Tim Wilson-Brown - teor]

> On 27 Jan 2016, at 18:19, grarpamp  wrote:
> 
> On Wed, Jan 27, 2016 at 12:00 AM, Virgil Griffith  wrote:
>> No wrong answer---just wondering what is the community's vibe on this
>> issue.  I can go either way.
> 
> Same IP excepting NAT is same box, kind of pointless if
> they're not the same entity [1], err to caution and call it family,
> put them in touch or encourage one or both to move or shutdown.
> 
> [1] Same entity would make sense if it was that entities
> chosen / available way of binding multiple cpu cores to
> tor instances, at least as far as the daemons go without
> considering overall utility to tor.

Tor already considers relays in the same IPv4 /16 to be in the same family.
See nodelist_add_node_and_family() and addrs_in_same_network_family() in the 
tor source.

Whether OnionOO should reflect this is another matter.

Perhaps it could imitate Tor, and have a separate field called "network family"?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Tim Wilson-Brown - teor]

> On 29 Jan 2016, at 07:20, Roman Mamedov  wrote:
> 
> On Fri, 29 Jan 2016 06:33:51 +1100
> Tim Wilson-Brown - teor  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.

If OnionOO added it, it would save OnionOO clients some work.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Roman Mamedov]

On Fri, 29 Jan 2016 06:33:51 +1100
Tim Wilson-Brown - teor  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.

-- 
With respect,
Roman


pgpCxw4WNA27Y.pgp
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Virgil Griffith]

They are indeed configured in torrc.  The question is whether two relays on
the same IP# *should* be in the same family even if they aren't.

-V

On Wednesday, 27 January 2016, Tristan  wrote:

> Aren't family members configured in torrc?
> On Jan 26, 2016 11:01 PM, "Virgil Griffith"  > wrote:
>
>> For example, these two pairs of relays that came online yesterday:
>> *
>> https://atlas.torproject.org/#details/0ED2D734F295427E5A3719FA7B9985C335839123
>>
>> *
>> https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D132A3
>>
>> and
>>
>> *
>> https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D132A3
>> *
>> https://atlas.torproject.org/#details/2FF21F475C2E668C23DB7625A9D45B52591B30FD
>>
>> (Hat-tip to Sean Saito for pointing these out.)
>>
>> No wrong answer---just wondering what is the community's vibe on this
>> issue.  I can go either way.
>>
>> -V
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[grarpamp]

On Wed, Jan 27, 2016 at 12:00 AM, Virgil Griffith  wrote:
> No wrong answer---just wondering what is the community's vibe on this
> issue.  I can go either way.

Same IP excepting NAT is same box, kind of pointless if
they're not the same entity [1], err to caution and call it family,
put them in touch or encourage one or both to move or shutdown.

[1] Same entity would make sense if it was that entities
chosen / available way of binding multiple cpu cores to
tor instances, at least as far as the daemons go without
considering overall utility to tor.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[Tristan]

Aren't family members configured in torrc?
On Jan 26, 2016 11:01 PM, "Virgil Griffith"  wrote:

> For example, these two pairs of relays that came online yesterday:
> *
> https://atlas.torproject.org/#details/0ED2D734F295427E5A3719FA7B9985C335839123
>
> *
> https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D132A3
>
> and
>
> *
> https://atlas.torproject.org/#details/667C297D3EC6E1281D68F7F4C8C9BE8324D132A3
> *
> https://atlas.torproject.org/#details/2FF21F475C2E668C23DB7625A9D45B52591B30FD
>
> (Hat-tip to Sean Saito for pointing these out.)
>
> No wrong answer---just wondering what is the community's vibe on this
> issue.  I can go either way.
>
> -V
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays