At 16:33 01/03/01 +1030, Ben Nagy wrote:
>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.
That's understandable (though I keep my opinion:)
>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.
agreed, it's more of a "principle" question.
>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.
Isn't this an over eng approach? It has the beauty of generality, but doesn't
it make things more complicated than they should (well, it's not that
complicated, but a "limited" version is simpler).
>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.
yes, that's what I don't like, even if this is not a serious problem (note
that if it was
really a serious problem, then the implementations that do it this way
would be bad,
which not the case:-)
>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 was mostly thinking of IP in IP encapsulation protocols (aka IPSec).
If you use a setup like:
client --- encapsulator --- NAT box ---- decapsulator ---- server
then the NAT box won't see the inner packet and will only NAT the outer
headers.
if you change and put the NAT box before the encapsulator, then the latter
loses
infos about the client.
You might say that this is a problem of "encap+NAT", not just NAT. Or that's a
problem of IP! (which is true!).
>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.
I agree that most of these are a problem not only for NAT but also for
filtering.
>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.
I overlooked the open/closed spec side. but my intent was to say that the
fact that
NAT works great isn't sufficient to justify it.
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
