[tor-dev] Connection, Channel and Scheduler - An Intense Trek

[David Goulet]

On 01 Nov (14:28:03), teor wrote:
> 
> > On 31 Oct 2017, at 06:57, David Goulet <dgoulet at ev0ke.net> wrote:
> > 
> > * I believe now that we should seriously discuss the relevance of channels.
> >  Originally, the idea was good that is providing an abstraction layer for the
> >  relay to relay handshake and send/process cells related to the protocol. But,
> >  as of now, they are half doing it.
> > 
> >  There is an important cost in code and maintanance of something that is not
> >  properly implemented/finished (channel abstraction) and also something that
> >  is unused. An abstraction implemented only for one thing is not really useful
> >  except maybe to offer an example for others? But we aren't providing a good
> >  example right now imo...
> > 
> >  That being said, we can spend time fixing the channel subsystem, trying to
> >  turn it in a nicer interface, fixing all the issues I've described above (and
> >  I suspect there might be more) so the cell scheduler can play nicely with
> >  channels. Or, we could rip them off eliminating lots of code and reducing our
> >  technical debt. I would like us to think about what we want seriously because
> >  that channel subsystem is _complicated_ and very few of us fully understands
> >  it afaict.
> 
> It depends what the goal of the channel layer is.
> 
> Do we seriously think we will use another protocol in place of TLS?
> 
> Even if we are serious about non-TLS connections, do we want to rip out
> this code now, and write something better when we know what we
> actually need?

Right, that is basically a very good question to try to answer. I think it is
totally conceivable to think about researchers willing to experiement there
and go with a Tor without TLS. At that point, channel could be useful but in a
state that actually is a proper abstraction (not the case right now). We would
need work to make it happen.

However, I do *NOT* see Tor moving away from TLS anytime soon. The network and
clients out there are all using that, moving to something else would mean dual
stack protocol, years of ramping up to network maturity (basically ntor vs tap
is a good example I think). But at that point, we'll have to do massive amount
of work in the channel/connection subsystem.

All in all, my answer is that "No, we aren't serious about moving away from
TLS but always possible".

Thus, in the end, this channel subsystem is really about letting researchers
play with it and not helping us developers do our job. There could be a gain
there of fixing it but would be one sided for now imo.

> 
> Is the channel layer the right place to hide the differences between
> TLS-over-IPv4 and TLS-over-IPv6?

That would be the connection layer, handling 1 to 1 socket connection and
talking to the kernel.

SCTP-Tor for instance, would also be at the connection layer. That subsystem
in my opinion would benefit *greatly* for a nice interface but that is huge
amount of work.

Thus, I want to re-iterate that if we care about providing a nice abstraction
for researchers to do a better job, we have a broken one at the channel layer
and none at the connection layer which is actually the one that would be most
useful (QUIC, SCTP, UDP, ...). So even today we do *not* offer anything useful
to researchers imo.

Cheers!
David

> (I don't think it is, but it's worth thinking about how much work it
> was to add IPv6 support, and using that as a guide for how much work
> it would be to add address/port/keys/etc. for another protocol.)
> 
> T
> 
> -- 
> Tim / teor
> 
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
sGwH3ikKXaZjLVTHXKbL8U8r+dQrx5mLsny/C4ZarV4=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171101/52426f79/attachment.sig>