Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!op.net!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: IP Masqerading?
Date: Fri, 16 Aug 1996 18:05:20 -0700
Organization: Me
Lines: 254
Message-ID: <32151AD0.699795F7@lambert.org>
References: <jfortes-1307951117380001@10.0.2.15> <320F6E48.1EF468BB@lambert.org> <4urdc4$87m@herald.concentric.net> <32127AB2.21876B97@lambert.org> <4v0lsb$6uv@cronkite.cisco.com>
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)
Tim Iverson wrote:
] Here's the rest of my response ... don your asbestos, Terry!
]
] |> Socks is very application specific. It would be nice to have a more
] |> general solution. Isn't masquerading more general ?
] |
] |No, it is not. It is invalid because it violates the
] |following RFC's:
]
] Hmmm. This seems to directly contradict the Socks-5 RFC. Allow
] me to quote RFC-1928 3.:
]
] "When a TCP-based client wishes to establish a connection to
] an object that is reachable only via a firewall (such
] determination is left up to the implementation), it must
] open a TCP connection to the appropriate SOCKS port on
] the SOCKS server system."
]
] In other words, if your application doesn't support socks, you
] can't use it. So, NAT is more general than Socks.
This is technically true, but misleading.
Typical use of NAT (at least in the Linux sense, and in the
sense where you would require direct translation) does not
involve a firewall. It involves:
1) Someone who doesn't want to pay their ISP for more than
one address.
2) Someone who doesn't want to pay their ISP for packet
forwarding.
3) Someone who wants to run an MS OS which is not itself
SOCKS aware and is too lazy to install the SOCKS aware
WSOCK32.DLL
Basically, it's for lazy people or cheap people.
I have no problem with people being cheap, but they should admit
that that's what they're doing instead of trying to cloak it in
better robes.
I have a problem with lazy people. But, since I don't want to
force my world view down everyone's throat (or more likely, I
simply can't 8-)), the least they can do is, once again, admit
it.
] Second, if you have a daemon that catches direct requests and
] translates them into socks requests, you have done *precisely*
] what NAT does.
Not exactly. You have achieved precisely the same effect, but
you've done it without crapping in the kernel (so to speak).
It's more elegant to handle the issue in user space (mostly
as a tacit admission that "we are doing something that isn't
a very nice thing to do".
] The difference is that you now need a daemon on every client
] to perform the socks translation instead of just a single NAT
] agent on the firewall.
Actually, you route packets from the local network (which you
give one of the non-routable addresses) into the tunnel and
therefore to a socks client. The socks daemon runs on the
same machine, and you have a static route which you *don't*
locally advertise, and which differs from the default route
on the network (which will be the firewall's card address on
the local net).
So you only run one extra daemon, and you run that on the
firewall.
As far as the local net machines are concerned, you are routing
bidirectionally a non-routable net, to all appearances.
So it's incorrect to claim that my "ideal soloution" to this
"problem" requires extra daemons or anything else.
] Also, while we're on the subject of RFCs -- they are not law.
] They're just a *guideline* on how to achieve interoperability.
] Strict adherence to all RFCs does not come close to guaranteeing
] functionality.
It comes closer than strict violation of all RFCs. 8-).
] Lastly, not all NATs are created equal. Some break lots of
] RFCs, others do just a good a job as socks-5+firewall. In all
] cases, it depends on both implementation and installation. YMMV
] is the law here.
Yes. Although I believe all NAT's have to break at least some
RFC's.
] |o RFC-1919... "Classical versus Transparent IP Proxies".
]
] This "breakage" is merely a warning that indiscriminate use
] of transparent proxies (eg. NAT without a filter), can result
] in a breach in your firewall.
Given that there are typically better alternatives to NAT in all
but a few cases (*real* range translation, for instance), I will
pretty much put all NAT usage in the category "indiscriminate use".
8-).
] |o RFC-1256 ICMP router discovery doesn't work through a
] | "masquerade".
]
] It doesn't work past a firewall, either, nor would you want it
] too. In essence, so what?
Typical NAT usage is to overcome some specious economic setup,
and is not in the context of a firewall. If any of the RFC
arguments don't hold water, it would be my RFC-1919 argument
(which still holds water in the full "range translation" case).
] |o RFC 1063 MTU discovery doesn't work through a "masquerade";
]
] Uh, and why not? Even blind NAT will have no problem properly
] conveying the information for this option,
Use of ICMP packets.
] which may not even be supported by the client hiding behind
] the NAT.
Now who's picking bogus starting points? 8-).
] |o RFC-1477 IDP touches on proxy requirements which seem to not
] | be met by "masquerading".
]
] Again, if the NAT supports IDPR, you'll have no problem using
] it. I doubt anyone using FreeBSD will want to use it.
As you point out, not all NAT's are created equal. The IDPR
argument is weak.
] |o RFC 1935 "Looking at Firewalls", paragraph 2. Using "IP
] | masquerading" would allow a client to supply outside
] | services.
]
] <sigh> So what? If you need NAT, use it. Yes, it takes quite
] a bit of work to keep a *large* NAT'd network secure, but most
] of us that *need* NAT are running small and relatively simple
] networks that are easy to secure.
Again, it's not this use that's at issue. It's the use of NAT as
a lazy-man's fix for something that should be fixed another way.
My biggest objection is that an half-working soloution will
tend to disincent people from building an actually working
soloution. Pretty soon, it's common practice, and then you
have another monster on your hands, like SLIP, or like the
Microsoft PPP "extensions", or like the lack of standards
compliant ISP access mechanisms, so I need to use something
like ISP-equipment-specific "chat" scripts to change from one
ISP to another.
>Bletch<.
] |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.".
]
] You're really reaching here. Accounting is always a matter
] of personal taste and NAT or not, you can always add more to
] meet your needs.
I admit it. The point was to target technical non-compliance
arguments exhaustively. Many such arguments can be argued
around on a situational basis, but the more you argue around,
the more twisted the path to your "general case". Pretty soon
it becomes clear that there has got to be a more elegant soloution.
] |1) Socks5 -- that's Socks****5**** -- supports proxying without
] | modifying applications.
]
] Absolutely it does not. See above, where I quoted RFC 1928,
] the SOCKS-5 protocol spec.. If your app doesn't support the
] socks protocol or you don't have a daemon performing translation
] to socks-5, you're SOL. And, daemon+socks is exactly the same
] as NAT+filter, not to mention that the only translating daemon
] I know of is for Win-95 and is somewhat buggy.
It's actually a DLL, and I'll give you that one. I'd prefer to
implement using the tunnel on the proxy host (not firewall).
But of course, as long as people keep making halfway usable
soloutions available, no one is going to buckle down and Do The
Right Thing. 8-(.
] |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 enable some types of
] | packet forwarding.
]
] This is incredibly misleading. Using NAT may cause *you* some
] problems if you try NAT'ing a large network. It almost certainly
] won't cause anyone else any problems unless you do something
] grossly incorrect, like NAT to someone else's IP block.
It's factual. However, it seems that your use of NAT actually
falls into the class of "translative bridging". This is somewhat
different than the use that most of the people, with PC's and a BSD
box with a 28.8 modem keep screaming for it, want to put it to.
In your use, it would be reasonable to actually bridge datagram
traffic; since non-requested datagrams are ignored, this should
be acceptable for averything but working multicast.
] Obviously, you have something of an axe to grind wrt. NAT
My only axe is that it irks the bejesus out of my elegance
filter. 8-).
] NAT on large networks can be a nightmare. However, used
] judiciously, it can be a godsend on smaller networks. I
] save several hundred dollars a month using NAT to a single
] IP instead of renting an IP block and I don't really see any
] compelling reasons to abandon IP-Filter + NAT in favor of
] Socks-5 + ipfw. Quite the opposite, in fact.
I'd just prefer it to be impossible to turn on RFC violations
in a stock system without having to run "admittedly nasty, but
acceptable as a kludge for some people" user space software.
I'd also like to see a more general soloution that could be
applied to more generic systems. For instance, boxes for
which you can't recompile the networking, but which are full
fledged UNIX or other boxes, and don't have any chance of
supporting a tunnel device themselves.
Like I said, it triggers my elegance filter. Nothing personal.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.