Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!news.uoregon.edu!arclight.uoregon.edu!usenet.eel.ufl.edu!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: "Masquerading is evil"
Date: Wed, 14 Aug 1996 18:04:01 -0700
Organization: Me
Lines: 78
Message-ID: <32127781.4D10CDA9@lambert.org>
References: <Pine.BSF.3.91.960812161957.13996B-100000@darkstar>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Charles Mott wrote:
]
] I have completed an IP masqerading adaptation
] to the user mode ppp program distributed with
] FreeBSD. The software may be found at:
]
] http://www.srv.net/~cmott/alias.html
]
] I was intrigued by an earlier comment that
] "masqerading is evil." What did this mean?
] Having gone through a ground-up implementation,
] I have some idea what the author of this
] statement meant. My own judgment is that
] masquerading is imperfect, but very useful
] in certain situations.
If you meant my statement to that effect, I was specifically
referring to IP masquerading implemented per the Linux method
as a shortcut to writing a socks client on the end of a tunnel
device, and setting a couple of default routes.
My specific complaint is RFC non-compliance:
o RFC-1919... "Classical versus Transparent IP Proxies".
Socks is a classical proxy; a socks client daemon using an
IP tunnel for traffic encapsulation on a transport is a
transparent proxy. "IP masquerading" is neither. Section
4.2.5 is especially applicable.
o RFC-1256 ICMP router discovery doesn't work through a
"masquerade".
o RFC 1063 MTU discovery doesn't work through a "masquerade";
(clearly, the MTU should be lower than for an ethernet for a
PPP based "masquerade server").
o RFC-1477 IDP touches on proxy requirements which seem to not
be met by "masquerading".
o RFC 1935 "Looking at Firewalls", paragraph 2. Using "IP
masquerading" would allow a client to supply outside
services.
o RFC 1272 requires that "proxy agents have to do their own
accounting for services, since the network cannot
distinguish on whose behalf they are acting.".
What you describe implementing is a transparent proxy in the
PPP code, which is an RFC-1919 compliant implementation, not
an adulteration of the main line networking code.
For what it's worth, correct soloutions (like yours) are fairly
easy; there's no excuse for "IP masquerading" in the sense that
it has been typically used:
1) Socks5 -- that's Socks****5**** -- supports proxying without
modifying applications.
2) You can use NAT. Be aware that you are in violation of the
RFC's which you must implement to be allowed on the Internet
as a "good network citizen" if you choose to forward some
types of packets as if the proxy server were a gateway.
3) Using a tunnel device and static route asignments for internal
networks, and a socks-using-daemon (which no one has written
yet because they would rather violate RFC's than really solve
the problem or get valid address assignments and route them),
it is possible to support "local net" encapsulation over the
tunnel device to implement RFC compliant transparent proxy
services.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.