Opened 8 months ago

Last modified 4 months 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: SponsorV-can

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 (7)

comment:1 Changed 8 months ago by teor

Points: 3
Sponsor: SponsorV-can

comment:2 Changed 8 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 8 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 7 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 5 months ago by nickm

Keywords: 034-triage-20180328 added

comment:6 Changed 5 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 4 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.

Note: See TracTickets for help on using tickets.