Re: Application protocols and Address Translation

paf said:
> - Security is handled by a firewall, not the
> NAT function
> - Security is always in the form of some
> policy which someone want to apply to a path
> - If the policy allow application FOO to pass
> the point where policy is applied, the application
> will only work as planned if there is _NO_ nat
> at that point
>
> I.e. talk about security <> NAT and that NAT
> is bad for things which the policy allow.
>
> Do you think that can help?

It's a start, but in many companies, the policy in place dictates that no
external connections to internal addresses may be made. Furthermore, many
companies use black-hole routing to control external access; i.e., they're
using double-NAT on the gateways to completely isolate the networks'
addressing, and force use of an intermediary in the DMZ for all traffic
from the inside to out.

When such extreme policies are in place, NAT makes sense to administrators
as one tool; implementation is simple, meaning there's less chance of an
exploit against the device itself (as compared to a firewall). Of course,
it must be used in conjunction with a firewall, but having multiple layers
of policy applied increases security in their eyes.

The configuration outlined above was that used at my former employer, a
financial services company with over four trillion USD under management
(much less now ;).

The opportunity cost of limiting new applications was dwarfed by the risk
of having externally-addressable hosts, so they used NAT. If you can
refute this argument for security, it would be good to include it in such
a paper, but IMO it won't convince them no matter how well-reasoned.

I think time arguing against NAT would be better spent talking about why
it shouldn't be deployed for general-purpose access (e.g., in home
routers, wireless bridges, at ISPs, conferences, hotel rooms, etc.). In
particular, it should address the issue of why using number of IP
addresses used as a charging model for access is a bad idea.

Cheers,

Received on Monday, 2 December 2002 17:28:59 UTC