At 09:33 26/02/01 +1030, Ben Nagy wrote:
>Any NAT implementation that is not brain dead should block any packets that
>are not addressed to a valid NAT translation (IP addr AND port, unless it's
>a static or 'weird' translation).
I have to disagree here. I use NAT to translate addresses and a packet
filter to filter
packets. I don't want my NAT to take filtering decisions, cos' I have a
better thing to
do it: a packet filter. That's the "do your job well, but don't do anything
else"
principle. When everyone keeps his cows, everyone gets milk:)
There is absolutely no reason that NAT should block any packet. I might as well
like the packet to get passed, either to allow it or to pass it an IDS.
>You should also be able to configure NAT to _not_ translate stuff, based on
>ACLs of some kind,
All the NATs I've seen have rule of the form:
if dest is xxxx, then convert to yyyy
I've not yet seen rule of the form:
if source is aaaa and dest is bbbb, then convert dest to yyyyy
NAT maps objects (addresses) while ACLs are oriented toward a
"condition => decision" way. The latter may include NAT but not the
converse.
> and thus explicitly configure your edge device to allow
>untranslated traffic to traverse (still in a stateful fashion), but if it
>can happen by default then the code monkey responsible for that NAT
>implementation gets no banana.
The problem is how other modules will know that traffic is "untranslated".
This is a state variable that is lost once you get out of the NAT module.
So unless NAT and the filter are implemented in a sinlge module, you're
out of luck.
>That's why NAT provides pretty reasonable security - as good as a dumb
>stateful packet filter, anyway. In my experience, most of the protocols that
>tend to get broken by NAT don't bother me anyway.
This amounts to to stating that NAT developpers will implement specific
things to make the protos that bother you compatible. That would be ok,
but there are 2 problems:
- they will only make efforts if there is sufficient "sponsor" (they won't
do it
just because you like it)
- this may be very hard or simply impossible (IPSec, ...)
The thing that should bother you is that people can no more develop nice
protocols unless they can make'em work with NAT, since the latter seems
to be everywhere. This means that there are silly constraints on new protocols.
Your argument is the same as saying: I use windows, and everything is ok
with it.
There is no reason to develop open protocols. It suffices to use MS based
protocols
and methods. All the other stuff that don't work with windows don't bother me.
This is reasonable and common practice. But it don't get us far from here...
Evaluating a technology doesn't amount to checking whether it is compatible
with our
current practices/needs, but requires that one also checks whether it will
be good for
the future.
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
