[metrics-team] onionoo exit_addresses semantics

[nusenu]

thank you for your reply, yes it is still relevant to me (with the goal to 
reduce OrNetRadar false-positives).

Karsten Loesing:
>> https://metrics.torproject.org/onionoo.html#details_relay_exit_addresses
>>> Array of IPv4 or IPv6 addresses that the relay used to exit to the
>>> Internet in the past 24 hours. IPv6 hex characters are all
>>> lower-case. Only those addresses are listed that are different from
>>> onion-routing addresses. Omitted if array is empty.
>> Depending on the interpretation of
>> "Only those addresses are listed that are different from
>> onion-routing addresses."
>>
>> this is a potential bug or not.
> Onionoo takes exit lists and includes all IP addresses that have been
> found in scans over the past 24 hours. It does not combine this
> information with older consensuses to see if an exit IP address was in
> fact a former OR address.
> 
> Stated differently, the only reason for excluding exit addresses that
> are currently known as OR addresses is deduplication.

and "currently" is not relative to "at the the time of the scan".

to have something that would match my initial interpretation of the
exit_addresses field, this would require a change in the scanner
producing the exit lists to enrich the output with information about
whether a given exit IP was also the OR IP _at the time of the scan_.

so in this example:
https://metrics.torproject.org/collector.html#exit-lists

these two lines would have a new field at the end:
ExitAddress 91.102.152.236 2010-12-28 07:10:30  OR
ExitAddress 91.102.152.227 2010-12-28 10:35:30  NON-OR

and then onionoo would then only care about NON-OR lines
but without that there is not much onionoo could do 
without starting to include OR IPs data from the past 24 hours.
 
 
> I could see us do three things here:
> 
>  1. Stop deduplicating exit addresses and just include everything from
> exit lists found in the past 24 hours. Would this help?

I don't see any use-case for that, since that would mean that exit_addresses
field would just be a copy of the already included OR IP in ~930 out of ~970 cases.

>  2. We clarify the specification by saying that we're not checking
> whether an exit IP address was a former OR address, but that we're just
> deduplicating.

That is better than nothing.

>  3. We do nothing.
> 
> Maybe there's a 4 here, or a variant of 1 or 2.
> 
> If this turns out to require new code, let's move the discussion to Trac.


Until now a non-empty exit_addresses field meant to me: 
(a) "oh look this relay
is doing some NAT, using OutboundBindAddressExit or doing some other rerouting"

but it actually might also be: "this exit might has changed his OR IP recently" (b)

I'm wondering how most people interpret that field after reading its description. 


I've some ideas on how I could eliminate (or at least reduce) OrNetRadar false
positives (by ignoring candidates where last_changed_address_or_port is within
the last 24 hours). 


thank you for conforming my observation and improving my 
understanding of the exit_addresses field.

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20180216/8d01e94c/attachment.sig>