On Sat, Mar 14, 2020 at 12:44 AM teor <t...@riseup.net> wrote: > > Hi Nick, > > I'm interested in following along with Walking Onions, but I might > drop out when the relay IPv6 work gets busy. > > I'm not sure how you'd like feedback, so I'm going to try to put it > in emails, or in pull requests. > > (I made one comment on a git commit in walking-onions-wip, but > I'm not sure if you see those, so I'll repeat it here.)
Thanks, this is really helpful! I missed the repository comments, and I'll probably miss some more. > > On 14 Mar 2020, at 03:52, Nick Mathewson <ni...@torproject.org> wrote: > > > > This week, I worked specifying the nitty-gritty of the SNIP and > > ENDIVE document formats. I used the CBOR meta-format [CBOR] to > > build them, and the CDDL specification language [CDDL] to specify > > what they should contain. > > > > As before, I've been working in a git repository at [GITHUB]; you > > can see the document I've been focusing on this week at > > [SNIPFMT]. (That's the thing to read if you want to send me > > patches for my grammar.) > > I'm not sure if you've got to exit ports yet, but here's one possible > way to partition ports: > * choose large partitions so that all exits support all ports in the > partition > * choose smaller categories so that most exits support most ports > in the partition > * ignore small partitions, they're bad for client privacy anyway > > For example, you might end up with: > * web (80 & 443) > * interactive (SSH, IRC, etc.) > * bulk (torrent, etc.) > * default exit policy > * reduced exit policy > > I'm not sure if we will want separate categories for IPv4-only > and dual-stack policies. We can probably ignore IPv6-only > policies for the moment, but we should think about them in > future. Interesting! Yeah, something like this might work. I've added this to my notes. Also, there's some interesting ideas about handling exit policies in the whitepaper's section 6. I don't know if > > There were a few neat things to do here: > > > > * I had to define SNIPs so that clients and relays can be > > mostly agnostic about whether we're using a merkle tree or a > > bunch of signatures. > > > > * I had to define a binary diff format so that relays can keep > > on downloading diffs between ENDIVE documents. (Clients don't > > download ENDIVEs). I did a quick prototype of how to output > > this format, using python's difflib. > > Can we make the OrigBytesCmdId use start and length? > length may be shorter than end, and it will never be longer. Good idea; done. > If we are doing chunk-based encoding, we could make start > relative to the last position in the original file. But that would > mean no back-tracking, which means we can't use some > more sophisticated diff algorithms. Well, we could allow signed integers. I'm making a note to look into whether this would help much. [...] > If the issue is having multiple valid ENDIVEs, then authorities could > also put a cap on the number of concurrently valid ENDIVEs. > > There are two simple schemes to implement a cap: > * set a longer interval for rebuilding all ENDIVEs > (the cap is the rebuild interval, divided by the validity interval) > * refuse to sign a new SNIP for a relay that's rapidly changing > (or equivalently, leave that relay out of the next ENDIVE) > > Both these schemes also limit the amount of bandwidth used > for a relay that's rapidly changing details. Interesting idea; I think in the case of the first one, we'd be giving up something important, but I don't know how much so. The second one might actually help with our network stability, though. [...] > > Do "tricky restrictions" include the IP subnet restriction (avoid > relays in the same IPv4 /16 and IPv6 /32) ? I'm thinking of _all_ tricky restrictions, including but not limited to IP subnets, families, user settings, and > What about a heterogenous IPv4 / IPv6 network, where > IPv4-only relays can't connect to IPv6-only relays? This one would fit more into "alternative topologies", but I think the design can handle that. (See proposal 300 section 3.9.) The way it would work is, you put IPv4-only relays into group A, dual-stack relays in group B, and IPv6 relays into group C. Then you give them different successor lists, so that A has successor in A and B, C has successors in B and C, and B can have all successors. > If we do decide to add IPv6-only relays, we'll probably add > them in this order: > * IPv6-only bridges (needs dual-stack bridge guards / middles?) > * IPv6-only exits (needs dual-stack middles) > * IPv6-only guards (needs dual-stack middles) > * IPv6-only middles (needs dual-stack or IPv6-only guards and > exits, removes need for dual-stack middles) > > What about bridge guards? > (That is, can bridges add an extra hop into circuits, to protect > themselves from being discovered by middles?) Yes, that should still work with the base design. I'll need to think more about how it would work in non-clique topologies, though. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev