Date: Sat, 18 May 1996 01:24:18 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: terry@lambert.org (Terry Lambert) Cc: alk@Think.COM, questions@freebsd.org Subject: Re: ip masquerading Message-ID: <199605180824.BAA02382@bubba.whistle.com> In-Reply-To: <199605180548.WAA22030@phaeton.artisoft.com> from "Terry Lambert" at May 17, 96 10:48:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Actually, it requires a "socks" layer in the TCP/IP code you put
> in your toaster.
>
> It's not like you can ROM GPL'ed Linux code anyway, which is the
> only place masquerading is implemented.
>
> > Sorry, but my toaster is not going to fulfill host requirements.
> > In order to conform to rfcs, I need something to provide masquerade
> > for my toaster, otherwise I will never be able to turn of the stupid
> > thing when I'm in Bangkok, and the flaming pop-tarts will burn down
> > my house.
>
> Well, feel free to write "masquerading" instead of a socks tunnel;
> it should take you about twice as long. No skin off my nose.
>
> You might be real pissed when you try to get it integrated into
> the kernel sources, though... I don't think Garrett has gone
> insane yet.
I've already written masquerading (I call it "address translation")
as part of a revised user-land PPP daemon, and it works great...
even handles FTP control stream hackery. Of course, this has nothing
to do with PPP. It's only because PPP, using /dev/tun0 on one side and
a serial link on the other, can act as such a filter.
I strongly agree it would be nice (and morally correct) to keep this type
of hackery out of the kernel.
There's a larger question here then, which is that we need a more
general mechanism for user-land "filtering" (in the most general sense)
of packets as they cross an interface. BPF and /dev/tun? are both
great, but you can't implement a filter with them.
Firewalling, encryption, and accounting are examples too.
Poul-Henning suggested some ideas about this a while back, but I
haven't heard if he plans on developing them.
A simple idea would be to have "detour" devices where you could
open /dev/filteri0 and /dev/filtero0, attach them to some interface,
and have all packets (optionally before or after (de)fragmentation)
passing through that interface routed up one and down the other.
Better yet, with devfs, they could even have names like /dev/if_ed1
and /dev/of_ed1 and no binding operation would be necessary. Then the
picture would look roughly like this:
--> /dev/if_ed1 -->
/ \
network <--> interface ed1 <--> <--> kernel routing
\ /
<-- /dev/of_ed1 <--
When either file is not open, packets pass normally without the detour,
and with normal kernel speed. When one is open, you get to play your
games with them but pay a penalty in speed. In the same way that user
land PPP has become more popular and widely developed than kernel land
PPP, even though it is supposedly slower, I think something like this
would also be a net gain both for fostering useful developments and
fighting kernel bloat.
I guess you could also do this just using the existing tunnel devices
with some kind of "redirect" ioctl().
Terry, what do you think of this idea? How would you design a general
purpose user land filtering mechanism?
-Archie
___________________________________________________________________________
Archie L. Cobbs, archie@whistle.com * Whistle Communications Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605180824.BAA02382>