> -----Original Message-----
> From: mouss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 27 February 2001 1:24
> To: Ben Nagy; Firewalls Mailing List (E-mail)
> Subject: RE: To NAT or not to NAT?
>
>
> 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).
>
[...]
>
> 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.
Difference of opinion. I believe that things should work with a deny base.
In other words, if the NAT module can't do anything sensible with an
incoming packet it should drop it, not pass it.
Not that it matters _all_ that much, since the reply packet would get
translated on the way out, so no 'session' is possible without hackery.
> >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
I'm not sure what you're getting at here (as in which direction you're using
src/dst in). Cisco NAT will allow you to NAT outgoing into as many pools as
you want based on almost anything you like (IP address, port, blah blah).
You can also configure it _not_ to NAT certain ranges.
[...]
> > 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.
Uh, why? You filter first, then NAT. If it gets past NAT then it must be
allowed. This is assuming that the NAT module has a deny base, though, which
you don't think is good.
> >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.
I don't see why the constraints are silly. To make a protocol that works
with NAT, you need to not imbed IP addresses in the data of the packet and
not use callback ports that are initiated from the outside. That just sounds
like good protocol design to me.
I don't dislike protocols _because_ they won't work with NAT. However, most
protocols that don't are Just Bad, since they do crazy things like the ones
I list above.
> 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.
No, it's not. For a start it has nothing to do with open / closed source,
which is an issue that carries a whole slew of preconception and baggage.
Your analogy is blatant distortion.
[...]
> cheers,
> mouss
Cheers,
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
