Hi Michael,
At 13:39 11/06/01 -0400, Michael T. Babcock wrote:
>I will admit that the security offered by a NAT solution is as a result of a
>design coincidence, not necessarily because of an original intent. However,
>that doesn't negate its existence.
agreed.
> > so you configure NAT to map the 10.* class to a global address (1.2.3.10
> > for example).
>
>This is where my comment about "modern nat" and Linux's IP masquerading in
>particular come in. In Linux, with masquerading, these mappings are not
>done on a multi-multi address mapping basis, they are made on a
>multi-(source IP + port) to a single source IP with a dynamic port.
I was exactly talking of exctaly this!
map 10.* (a huge class:) to a single address 1.2.3.10. While I didn't
mentioned portmaping,
I consider it a requirement.
>To
>re-state your scenario, if:
>
>a packet comes from 10.0.0.1 to the NAT,
>it is sent as being from 1.2.3.4, the address of the nat device, and
>assigned a dynamic source port number
yes, I was talking of this thing. I dunno of any NAT implementation that
does not
provide this functionality. In particular, this is in Darren's ipf and in
Cisco things.
> > now, when a packet comes from the internet, your NAT will check whether it
> > corresponds to a NAT session
>
>[snip]
>
> > This means NAT should not reject packets just because they are not part of
>a
> > mapping. As a result, NAT does not filter flow.
>
>How do you mean that the NAT does not filter flow?
Reread my example. if a packet is going to your DMZ (which has a public
address and
no NAT is used for it), then the NAT should not do anything about it, even
if it does not
correspond to a NAT session.
To be more precise, NAT only check packets destined to an address that is
subject to NAT.
and it is then optional to block those that do not correspond to a NAT
session, but this is
not mandatory (and in my opinion, but let's keep opinions to other threads,
this is not the
right place to do such filtering). But for any packet destined to an
address that has nothing
to do with NAT, NAT _must_ let the packet continue its life. This is not a
problem if you're
having an-all-NATted-network, that is you NAT everything out and NAT-back
everything in,
which is the "classical" application of Linux masquerading. but this is not
the case for everybody.
> > Besides, there is no modern NAT (NAT is NAT). What you are referring to is
> > a "suit" [sic] that does both NAT and filtering. so it is a solution that
>implements
>
>All the IP masquerading code does is a _modern_ version of NAT.
well, then it's a terminology debate. Then I invite your to read RFC 2663.
You have the right to call it modern if you want, but I see 3 problems:
- this thing already has too many names (npat/pat/pnat among other names.
Oh those merketers:).
- calling it modern would lead people to think that it obsoletes other forms
of nat, such as bidirectional NAT, static NAT, ... and this is simply untrue.
All these are useful for different purposes/situations.
- it's not that new. RFC2663 dates from August 1999. If you count the time
it took
to publish it, and the fact that this RFC cites it (so the concept was
known before),
then you'll see that it's not really new. I think it was already known in
1998 (if not before).
>Old NAT (to me) is internal source IP to dynamic/static external source IP
>mapping, on a multi-multi basis.
Again, I don't like calling one "old" and the other "modern" for the
reasons stated above.
Besides, this is what proxies have always did!
If a modern thing should exist, then it is RSIP.
>Modern NATs allow multiple internal source IPs to all be mapped to one
>external IP and do so by keeping some state information. This makes the
>internal network machines effectively invisible*
>
>* There are still ways to gather some information ... see insecure.org
you can also see the rfc3027
("Protocol Complications with the IP Network Address Translator")
for a list of problems/complications/... and the "NAT handbook" (this is
a printed book) explains why you should not use NAT if you don't really
need it!
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
