Date: Tue, 23 Apr 1996 13:18:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, pst@shockwave.com, current@FreeBSD.org Subject: Re: socks support native in freebsd? Message-ID: <199604232018.NAA20265@phaeton.artisoft.com> In-Reply-To: <199604230656.QAA09490@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 23, 96 04:26:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > By IP tunneling the default route to the socksd that then forwards > > it to the forwarding host using a static route to the real interface. > > How is this different from the already-deemed-evil Linux "IP Masquerading"? > The 'tunnel' approach either requires a socks-like protocol, which requires > application (or library) support, or it rewrites packet headers. It uses real routing. For masquerading, it would require noting the the socket level abstraction and going back down -- basically, an implementation to layer 4 on the tunnel program that then threw it back down and switch on the "response" bit and a decode of the IP packet contents for TCP packets based on target socket. I think UDP and ICMP echo datagram support could be handled, unlike in the IP masquerading case, but it would be a pretty hairy coding job. ICMP echo datagram (ping/traceroute) would be especially hairy, but might be handled by a monotonically increasing sequence and response LRU queue. Either way, unlike "Linux IP Masquerading", though ugly, it would still be in technical compliance with the RFC's. With the LRU's, it could be significantly more functional than "IP Masquerading". > > Local routes can also go to the local linterface statically, by net. > > Heh. That's the linterface that uses static to collect dropped routes? 8) 8-). "Ain't got a thing if you ain't got that cling"... Naw, just a typo. 8-). > Actually, Paul was talking about 'whatever is state-of-the-art'. Witness > the upcoming back-outs of the initial socks-4 stuff, and the implementation > of the (optional) socks-5 shared-library features. Yes. This makes simple socks implementation much, much nicer. It doesn't fix local socks-unaware Microsoft clients wanting to go through your single too-cheap-to-pay-for-multiple-addresses PPP connection to your provider, like Masquerading does, though. 8-). It does fix everything -- at least everything that's liked shared -- local to the BSD box, though. For HTTP, a cache server would fix the local clients (but then it wouldn't need socks to do it 8-)). > > Second, this is an atypical network configuration, and the average > > user should not have to pay for it in their libc. > > *snort*. There are a million warts that the 'average user' pays for already > in their libc. I would suggest that any overhead that Socks-awareness would > impose on the (small) number of relevant system calls would be noise > against interrupt latency on the average network interface. Well, you know me -- I'm a purist; *all* those warts should be burned off, if only to prevent them from being used as a justification for future warts. 8-). Not that this is really a problem for anything but statically linked code which is not already socks-aware once socks5 is there... > > > ...except that Netscape (at the least) already supports Socks, and in fact > > > goes so far as to support making TCP DNS queries so that a UDP proxy isn't > > > required. > > > > Fine. Pick a binary program other than Netscape which does not support > > socks. > > Hmm. Microsoft Explorer, perhaps. Yeah, that was my first pick too. Didn't want to admit it because it's another example of something not-so-nice that's going to be standard anyway, like it or not. I'm still worried about their non-SSL authentication using licensed RSA code. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604232018.NAA20265>