At what level does the NAT occur in the OSI model? So far I've heard 2 and
4... whats the right answer?
On 6 Jun 1997, Ryan Russell/SYBASE wrote:
> Criticisms are welcome.
>
> I was thinking today that I should say more about
> application-specific proxies vs. generic proxies.
> Socks is a good example of a generic proxy (at
> least I believe that is the case) and is indeed
> roughly equivalent to a packet filter, which is one
> of my points. At least you agree on that.
>
> One of the things I'd like to have to better educate
> myself is a list of proxies that do a good job of
> understanding and interacting with the protocols.
>
> But, I think my point still stands, that if you have
> more than a couple of protocols you have to
> proxy, and you want to utilize non-generic proxies,
> then you will end up using unrelated proxy software
> for some of the protocols (Your examples of
> RealAudio and SQLNet are good ones) and they will
> have different feature sets, security models, and yes,
> bugs. Translate bugs to mean potential holes or
> weaknesses.
>
> The converse of that could be: If you have n proxies
> that all understand and interact with the protocol
> in a meaningful way, and they all have 0 bugs,
> and they work exactly how you want, isn't that
> better than a layer 4 SPF? Yup.
>
> The above situation is a case where a SPF, as a
> unified security program, may be a better choice.
> It would be extreamly difficult to pick the cutoff
> point (i.e. if you have 5 proxies, just go to SPF) given
> that you probably lose some control over the protocols
> that you had before, but are now dealing with less holes, etc..
>
> BTW, doesn't the proxy for SQLNet exist because the
> protocol is complex, not to increase correctness of the
> data? I.e. a non-stateful packet filter would have to leave
> too many ports "open"?
>
> As for the last part of your note: I'll go back and
> re-read how I worded my conclusions, but what I mean
> to say is that generic proxies are equivalent to
> stateful packet filters.
>
> I also conclude that NAT is darn close to a generic proxy
> and a SPF, if you are using many-to-few translation
> and the NAT device doesn't allow the outside to initiate
> connections, which is probably a side-effect of most
> implmentations of many-to-few NAT.
>
> Thanks for the feedback.
> Ryan
>
>
> ---------- Previous Message ----------
> To: Ryan.Russell, firewalls
> cc:
> From: stoutb @
pios .
com (Bill Stout) @ smtp
> Date: 06/06/97 11:15:43 AM
> Subject: Re: Stateful Packet Filters vs. Proxies
>
> Forgive my criticisms:
>
> The paper is founded on some incorrect assumptions.
>
> It groups application specific proxies with generic proxies. Generic or
> 'plug-gw' proxies are not desireable because they don't filter application
> commands, and are viewed as nearly as weak as packet filtering. Application
> specific proxies are aware (to varying levels) of application commands.
>
> A proxy server typically comprises of application specific proxies, and does
> not comprise of only generic proxies. Generic proxies are avoided at all
> costs, at least until management wants 'something added'. Occasionally
> generic proxies are used as last resort, then replaced, for example
> RealAudio and SQLnet were initially filtered with plug-gw proxies until
> application (RealAudio/SQLnet) specific proxies were released.
>
> The paper then continues to compare generic proxy functions with packet
> filters and concludes they are the same. A discussion on NAT ensues which
> is not an equivalent technology to either.
>
> Bill Stout
>
> At 12:29 AM 6/6/97 -0400, Ryan Russell/SYBASE wrote:
> >Well, I finally got around to writing down my arguments
> >on the above subject. Check it out at:
> >
> >http://futon.sfsu.edu/~rrussell/spfvprox.htm
> >
> >Warning: It's lengthy.
> >
> >Comments welcome.
> >
> > Ryan
> >
> _____________________________________________________________________________
> Bill Stout (Systems Engineer/Consultant) stoutb @
pios .
com
> Pioneer Standard (Computer Systems & Components) http://www.pios.com/
> San Jose, CA (Location of 1 of 52 U.S. offices) (408) 954-9100
> *My opinions do not reflect that of the company, and visa-versa, thankfully.*
>
>
>
>
>
Follow-Ups:
References:
|
|
