> On Dec 10, 2015, at 03:08, George Michaelson <g...@algebras.org> wrote: > The 7 Layer model is a useful tool to talk about things, its not a rei-fied > thing. That said, apparent layer violations invite critique because they > inherently carry architectural consequence.
Very true. :-) > I think the overloading of a (semantic space) name to have special properties > to take it out of the system is a case in point. Its an application through > session layer property: packets don't get sent using .onion labels in > source/destination fields. Also true; most Tor Onion clients currently perceive Tor access as a (TCP) circuit to a SOCKS Proxy server which forwards packets onwards into a magic virtual network space where the layer-3-equivalent addresses are written strangely, indeed echoing the format of DNS addresses somewhat. :-) This is, of course, a complete heresy. All "real" network engineers know that "real" network addresses are written as dotted-quads of decimal numbers, like "127.0.0.1", except for newer ones where "real" network addresses are written like "::1" a-la RFC5952 The browser manufacturers - brazen fools that they are - have gone FAR beyond these bounds, delved deep into namespaces where the only the foolish will tread, and will allow URIs to represent otherwise pure, unsullied network addresses in non-canonical but supposedly equivalent ways such as: 0177.0.0.1 0x7f.0.0.1 127.0.1 127.1 2130706433 017700000001 0x7f000001 - and (worse!) because of Tim Berners-Lee's lack of foresight in using a colon to separate host from port, the ideal, visual purity of an RFC5952 IPv6 address must therein be encumbered with brackets - [square brackets!] - when used in a URL! HAS THIS INSANITY NOT GONE ON FOR TOO LONG ALREADY? And now, this upstart "Onion" thing. An 80-bit binary address which is encoded in base32? WHY BASE32? SURELY THERE IS NO PRECEDENT FOR USING BASE32? THE HUMAN EYEBALL ALREADY CANNOT COPE WITH THE VARIETY OF ENCODINGS WHICH ARE IN USE ON THE MODERN INTERNET! And worse: They FLAGRANTLY SUFFIX this 80-bit binary blob (16 characters base32) with a string: ".onion" - to FLAUNT its difference! What arrant perversion, the like of which we have not seen the like since X.25 NUAs & NSAPs! We should all march on the Tor office and Tell them! We should tell them to convert to Dotted Quads like any RESPECTABLE protocol does, so they can use: http://122.152.229.227.20.102.54.239.123.210/ ...which is FAR more obvious than "facebookcorewwwi.onion". Specifically: it is far more obvious that users would not be able to survive with such addresses without using DNS. Which is good, because that's what DNSOP loves to talk about. - alec (`dd if=cheek of=tongue`) :-P ps: Back when I was a young system administrator we had to remember addresses like 2342192001006995 and 00001300000001.FTP.MAIL; kids today have got it easy. > And the imposition on all the other layers to handle .onion specially, feels > (to me) a mortal wound. This, compared to the cost of taking syntactic limits > in the URI, and applying a lever there to wedge :tor: into the URI form, > denoting what you want to happen. > > SOCKS is pretty much a shim. Its a clean layer impact. Its (to me) like > taking fopen() and replacing it by bzip2fopen() to get silent bz2 capability > in existing file I/O > > On Thu, Dec 10, 2015 at 1:02 PM, John R Levine <jo...@taugh.com > <mailto:jo...@taugh.com>> wrote: > With onion you get a rather different thing that looks like an open > TCP connection, a couple of levels up the protocol stack. > > Strictly an Onion address yields you a _real_ TCP connection to your SOCKS > server, ... > > It's certainly a virtual circuit, but it's not a TCP connection because the > endpoints aren't IP addresses. > > The Onion addresses aren't making a "protocol switch", ... > > Really, they are. You can't do a DNS lookup on the address, there is no A or > AAAA record with an IP address to which you can open a TCP connection. > > Regards, > John Levine, jo...@taugh.com <mailto:jo...@taugh.com>, Taughannock Networks, > Trumansburg NY > Please consider the environment before reading this e-mail. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=T4UdyZF0g0I68UQdhjA_7A&m=ik7lMLqVVD8RLJ7MsB5cpctpfTj0ReD7tSvh88_miBc&s=ugYLtgSFAm8Krhwe0cKsgzpnrETYvUGL3evvpzmMMxg&e=> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
