Opened 19 months ago

Last modified 7 weeks ago

#24731 new defect

Stop checking routerinfos for addresses when we use microdescs for circuits

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, tor-relay, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: #24403 Points: 3
Reviewer: Sponsor:

Description

Directory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:

  • routerinfos (descriptors)
  • routerstatus (consensus)
  • microdescriptors

But they should check using the following order:

  • bridge routerinfos (descriptors)
  • routerstatus (consensus)

If using microdescriptors for circuits:

  • microdescriptors

Otherwise:

  • routerinfos (descriptors)

There is code that implements this algorithm in commits decb0636e2, 1d1c927b9a, and 4979ec3c17 of my bug23975_tree branch.

But this adds overhead to every address lookup when building circuits.

Maybe we can make it faster by:

  • not parsing routerinfos or microdescs if we aren't using them for circuits, or
  • putting a canonical address in node_t, updating it whenever ri, rs, or md change, and always using it

Child Tickets

Change History (10)

comment:1 Changed 19 months ago by teor

Points: 3
Sponsor: SponsorV-can

comment:2 Changed 19 months ago by teor

This also allows us to rewrite and simplify fascist_firewall_allows_node() and fascist_firewall_allows_rs(), as in commits a1a196db85 and ed704cbcb4.

comment:3 in reply to:  2 Changed 19 months ago by teor

Replying to teor:

This also allows us to rewrite and simplify fascist_firewall_allows_node() and fascist_firewall_allows_rs(), as in commits a1a196db85 and ed704cbcb4.

Actually, those are needed in #23975 for correctness.

comment:4 Changed 18 months ago by teor

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

The 0.3.3 freeze deadline has passed, all these children of #24403 belong in 0.3.4

comment:5 Changed 16 months ago by nickm

Keywords: 034-triage-20180328 added

comment:6 Changed 16 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:7 Changed 16 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:8 Changed 7 months ago by teor

#27248 would fix this, and many similar issues.

comment:9 Changed 7 weeks ago by gaba

Removing sponsor V as we do not have more time to include this tickets in the sponsor.

comment:10 Changed 7 weeks ago by gaba

Sponsor: SponsorV-can

Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.

Note: See TracTickets for help on using tickets.