[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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 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.

 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.

 > 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.

 > 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.

 > 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4297#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs