[146517] in North American Network Operators' Group
Re: Ok;
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Nov 15 10:05:58 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Date: Tue, 15 Nov 2011 07:00:25 -0800
To: Jay Ashworth <jra@baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>=20
> On the other hand, since a firewall's job is to stop packets you don't =
want,
> if it stops doing it's just as a firewall, it's likely to keep on =
doing it's
> other job: passing packets. It certainly depends on the fundamental =
design
> of the firewall, which I can't speak to generally... but you =
proponents of
> "NAT contributes no security" can't, either.
>=20
Perhaps this misunderstanding of the job of a firewall explains your
errant conclusions about their failure modes better than anything else
in the thread.
I would say that your description above does not fit a stateful =
firewall, but,
instead describes a packet-filtering router.
A stateful firewall's job is to forward only those packets you have =
permitted.
If ti stops doing it's job, it's default failure mode is to stop =
forwarding
packets. Please explain to me how mutilating the packet header makes
any difference in this.
>> That makes sense, but I'm wondering if that should be considered =
correct
>> behavior. Obviously a non-consumer grade router can have rules =
defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself =
is hosting
>> (http, etc), or c) be a port it explicitly forwards to the same =
inside
>> host.
>=20
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
>=20
> It is. And IME, the people who think NAT provides no security rarely =
if
> ever seem to address that aspect of the issue.=20
>=20
It's a lovely hypothetical description of how those devices should work.
IME, and, as has been explained earlier in the thread, it is not =
necessarily
how they ACTUALLY work. Since security depends not on the theoretical
ideal of how the devices should work, but, rather on how they actually
work, perhaps it is worth considering that our addressing reality =
instead
of theory is actually a feature rather than a bug.
> And, for what it's worth, I'm discussing the common case: 1-to-many =
incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, =
possibly on
> other ports.
I think that is what the discussion has been about all along.
Owen
