[tor-bugs] #4297 [BridgeDB]: Teach bridgedb how to handle descriptors with IPv6 addresses

[Tor Bug Tracker & Wiki]

#4297: Teach bridgedb how to handle descriptors with IPv6 addresses
-------------------------+--------------------------------------------------
 Reporter:  ln5          |          Owner:  aagbsn  
     Type:  enhancement  |         Status:  accepted
 Priority:  normal       |      Milestone:          
Component:  BridgeDB     |        Version:          
 Keywords:  ipv6         |         Parent:  #4563   
   Points:               |   Actualpoints:          
-------------------------+--------------------------------------------------

Comment(by aagbsn):

 Replying to [comment:14 karsten]:
 > Replying to [comment:13 aagbsn]:
 > > What do we do with bridges that listen on multiple ports or multiple
 addresses? (Or both?) Do you mean, they should be on a single line? Do we
 want to give out all the listening addresses and ports to a single client?
 Doesn't that circumvent the whole point of having multiple addresses and
 ports per bridge?
 >
 > We're talking about buckets here, right?  That means we export bridges
 in the unallocated ring to a file to be mailed to people distributing them
 ''somehow''.  I don't know if these people would prefer a single line per
 bridge with all addresses/ports or one line per address/port.
 >
 I believe they should get a list of lines that can be fed into a Tor
 client. Cut-n-paste, keep it simple.

 > Note that the number of addresses/ports per bridge is limited.  Proposal
 186 says there can be at most additional 8 addresses times 16 ports.
 Linus' implementation only allows for 1 additional address with 1 port,
 AFAIK.

 Correct me if I'm wrong, but doesn't the spec provide for port ranges?
 {{{
       or-address SP ADDRESS ":" PORTLIST NL

       ADDRESS = IP6ADDR | IP4ADDR
       IPV6ADDR = an ipv6 address, surrounded by square brackets.
       IPV4ADDR = an ipv4 address, represented as a dotted quad.
       PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
       PORTSPEC = PORT | PORT "-" PORT
       PORT = a number between 1 and 65535 inclusive.
 }}}

 BridgeDB #4297 supports port ranges, at any rate.

 >
 > > We want to avoid a scenario where single bridge operator could
 represent a majority of bridges by listening on a few thousand ports. For
 that reason, BridgeDB does not treat each address:port as a bridge, but
 selects a valid address:port from the bridge returned by the bridge
 distributor (https, email). Perhaps we should do something similar here,
 and write a single line per bridge, along with stability and reachability
 information.
 >
 > Without knowing how bucket files will be used, I could imagine that
 selecting 1 IPv4 and 1 IPv6 address per bridge would be sufficient for
 most use cases.
 >

 Yes. Most bridges probably wont listen on multiple ports at first --
 although it would be handy if the tor cloud images support multiple
 listening ports and/or addresses -- especially considering that more and
 more cloud providers offer ipv6 connectivity.

 > > Unfortunately, that information could be different for each address
 and the current implementation does not ensure that the same requesting
 (ip, email) will get the same address:port (Hmm. #5948 )
 >
 > So, staying in the bucket case, two subsequent runs shouldn't include
 different addresses for the same bridge in the file.  We could simply pick
 the first address for any given IP version or transport.

 That means that a bridge that gets (un)assigned to the bucket distributor
 will not utilize any of the additional addresses. Although, if the first
 address in the list gets blocked, it could be marked 'as blocked' and the
 next address in the list selected (if available).
 >
 > > BridgeDB will also need a patch to support 'is blocked' status for
 each valid address (or even address:port, as a compact representation or
 in a database - 65535 ports * 4 bytes * 8 address lines could add up in a
 hurry) #5949
 >
 > I wouldn't worry too much about database size here.  But you're right
 that blocking information should be at bridge:address:port detail.  If
 that makes things too complex, BridgeDB could only look at the bridge or
 bridge:address part.

 BridgeDB presently only looks at the bridge, because bridges only had one
 address:port.

 I don't think it's too complex, but this enhancement shouldn't block
 deployment of #4297 if it turns out to be harder than anticipated.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4297#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online