Opened 15 months ago

Closed 6 weeks ago

#26542 closed defect (fixed)

Distribute IPv6 bridges through bridges.torproject.org

Reported by: teor Owned by: phw
Priority: High Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords: anti-censorship-roadmap-october
Cc: jan@… Actual Points: 1
Parent ID: #24264 Points: 3
Reviewer: cohosh Sponsor: Sponsor30-must

Description

A relay operator can't find any IPv6 bridges on bridges.torproject.org:
https://lists.torproject.org/pipermail/tor-relays/2018-June/015512.html

Perhaps this is a bridge authority or BridgeDB issue.

Child Tickets

Change History (21)

comment:1 Changed 9 months ago by teor

As of 19 December 2018, there are still no IPv6 bridges on bridges.torproject.org with PT none or obfs4.

comment:2 Changed 9 months ago by teor

Parent ID: #28888

comment:3 Changed 9 months ago by teor

Parent ID: #28888#24264

We should check this ticket when Serge sets AuthDirHasIPv6Connectivity 1.

comment:4 Changed 9 months ago by darkspirit

Cc: jan@… added

comment:5 Changed 9 months ago by sysrqb

INFO      L81:request.withIPversion()  HTTPS request for bridges with IPv6 addresses.
INFO     L146:request.withPluggableT() HTTPS request for transport type: 'obfs4'
DEBUG     L78:geo.getCountryCode()     Looked up country code: CH                                                                                                                                                  
INFO     L125:request.withoutBlockIn() HTTPS client's bridges also shouldn't be blocked in their GeoIP country code: CH
INFO     L244:bridgerequest.generate() Adding a filter to HTTPSBridgeRequest for ${exit_node_address} for IPv6 obfs4 bridges not blocked in ch...
INFO     L300:distributor.getBridges() Attempting to get bridges for ${exit_node_address}...
DEBUG    L159:distributor.getSubnet()  Client IP was within area: ${exit_node_ip_netblock}
DEBUG     L44:filters.bySubring()      Creating a filter for assigning bridges to subhashring 1-of-3...
DEBUG    L325:distributor.getBridges() Client request within time interval: 1545318000
DEBUG    L326:distributor.getBridges() Assigned client to subhashring 1/3 
DEBUG    L327:distributor.getBridges() Assigned client to subhashring position: ${hash}
DEBUG    L328:distributor.getBridges() Total bridges: 1000
DEBUG    L329:distributor.getBridges() Bridge filters: bySubring1of3 byTransportNotBlockedIn(obfs4,ch,6)
DEBUG    L333:distributor.getBridges() Cache hit frozenset([<function bySubring1of3 at 0x7f50c6784c80>, <function byTransportNotBlockedIn(obfs4,ch,6) at 0x7f50bb0817d0>])
DEBUG    L269:distribute.bridgesPerR() Returning 1 bridges from ring of len: 0
DEBUG    L276:Bridges.filterDistinct() Got 0 possible bridges to filter

Where BridgeDB thinks the source address of the request was in CH.

comment:6 Changed 9 months ago by teor

Serge has enabled IPv6 reachability testing (#24264) and IPv6 bridge addresses appear in metrics (#28888).

But bridges.torproject.org still does not give out IPv6 bridges.

Is the IPv6 GeoIP missing?
Should we wait a few more days?

comment:7 Changed 9 months ago by gman999

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

comment:8 Changed 8 months ago by gaba

Owner: isis deleted
Points: 3
Priority: MediumHigh
Sponsor: Sponsor19
Status: newassigned

comment:9 in reply to:  7 Changed 8 months ago by teor

Replying to gman999:

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

Relays don't extend via IPv6, so any outbound IPv6 connections you see on an authority are reachability tests.
(We'll need better reporting of IPv6 once we do IPv6 extends, I added #29113 so we remember to add them to the heartbeat.)

Any inbound IPv6 connections you see are from clients using your authority as an entry. (Which should be rare.)

comment:10 Changed 5 months ago by gaba

Keywords: anti-censorship-roadmap-2019 added

comment:11 Changed 4 months ago by phw

Sponsor: Sponsor19Sponsor30-must

Moving from Sponsor 19 to Sponsor 30.

comment:12 Changed 3 months ago by gaba

Keywords: anti-censorship-roadmap added; anti-censorship-roadmap-2019 removed

comment:13 Changed 2 months ago by gaba

Keywords: anti-censorship-roadmap-october added; anti-censorship-roadmap removed

comment:14 Changed 6 weeks ago by phw

Owner: set to phw

comment:15 Changed 6 weeks ago by phw

Reviewer: sysrqb
Status: assignedneeds_review

Yes, this is a problem in BridgeDB. I fixed the distribution of vanilla IPv6 bridges in my fix/14065 branch.

Note that this patch doesn't fix the distribution of IPv6 PT bridges. The issue is that bridges currently cannot advertise both an IPv4 and an IPv6 address for pluggable transports (see #11211), which is why a bridge's transport line always contains an IPv4 address.

In theory, we could work around this issue by assuming that a PT bridge that has an IPv6 OR address also has an IPv6 PT address. This assumption may not always hold and BridgeDB is currently unable to do active scans to confirm if this is the case for a given bridge.

comment:16 Changed 6 weeks ago by arma

Summary: Distribute IPv6 bridges though bridges.torproject.orgDistribute IPv6 bridges through bridges.torproject.org

comment:17 Changed 6 weeks ago by phw

Reviewer: sysrqbcohosh

comment:18 Changed 6 weeks ago by cohosh

Resolution: fixed
Status: needs_reviewclosed

Looks good to me!

comment:19 Changed 6 weeks ago by cohosh

Resolution: fixed
Status: closedreopened

comment:20 Changed 6 weeks ago by cohosh

Status: reopenedmerge_ready

Sorry messed up the status, this is merge_ready >.<

comment:21 Changed 6 weeks ago by phw

Actual Points: 1
Resolution: fixed
Status: merge_readyclosed

Merged and deployed. Let's take care of PT IPv6 distribution over at #11211.

Note: See TracTickets for help on using tickets.