[146599] in North American Network Operators' Group
Re: Arguing against using public IP space
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Nov 16 18:11:50 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com>
Date: Wed, 16 Nov 2011 15:04:28 -0800
To: Jay Ashworth <jra@baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 16, 2011, at 10:58 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Owen DeLong" <owen@delong.com>
>=20
>> In this case, a router with NAT is slightly more likely to fail =
closed than
>> a router without NAT.
>=20
> "Slightly"? Continuing to assume here, as we have been, that the =
network
> behind a NAT is *unroutable*, then a NAT router has, IME, *many* more =
obvious
> possible failure modes which will make the internal network =
inaccessible from
> outside than modes which cause the opposite.
>=20
What matters is not the number of failure modes, but, the probability of
occurrence. Additionally, I have no reason to assume as you have been
that private addresses behind the NAT are for some reason "unroutable".
I would argue that this (sometimes) fallacious assumption may be one
of the key dependencies in your argument.
> If you're an attacker, targeting a behind-NAT box from the outside, =
then
> if the NAT's working, you can hit directly any ports that are =
forwarded to it.
>=20
Correct.
> If not, then you have to a) know the private IP of the box and b) be =
able to
> get packets to the last upstream hop with source routing on them and =
c) the
> box has to have failed (or been configured or built) in such a way as =
to=20
> *listen* to source-routing. Those layers may have varying =
thicknesses, but=20
> there *are* at least 3 more of them, *on top of* "did it fail in a way =
where
> it's listening at all?".
>=20
Incorrect.
a) I have to either know, detect, or guess at the private IP of the box =
(maybe).
b) I have to get packets to the last upstream hop. Source routing is =
just one tool
that could be used to do so. There are other possibilities.
c) The box doesn't have to listen to source routing. It has to accept =
packets
destined to it's exterior MAC address with an interior IP address (or =
other
address that causes it to meaningfully forward things inside).
>> However, a firewall without NAT is more likely
>> to fail closed than a router with or without NAT and equally likely =
to
>> a firewall with NAT.
>=20
> If it's a firewall that meets your definition of the word, as opposed =
to,
> say, a shorewall box, a smoothwall box, a pf box, or any of the other =
3 or
> 4 dozen packaged linux based firewall routers of which there are =
*lots* out
> there. Probably the most common failure more on those is "iptables =
accidentally
> cleared; box routes all packets".
>=20
Actually, if you configure iptables on those boxes correctly and turn =
off
ip forwarding (requiring instead that iptables actually do the =
forwarding,
which is possible), clearing iptables does not cause it to forward all
packets.
> That's one failure to get to that point, insted of 2, 3 or 4. And =
since it's
> human-based a lot of the time, it's probably even more likely.
>=20
I would argue it's at least two. First you had to configure iptables =
and/or
the OS incorrectly in order for clearing iptables to cause that problem.
Then you had to clear iptables.
>> In other words, NAT doesn't really improve =
anything,
>> but, the difference between the common failure modes of a firewall
>> vs. a router are worthy of consideration. The infinitesimal advantage
>> of NAT if you use a router instead of a firewall to perform the =
duties
>> of a firewall is dramatically overshadowed by the costs and damage
>> done by NAT.
>=20
> Costs already sunk, IME. Damage is a question-begging term here.
>=20
For IPv4, that argument can perhaps be made. Since the question was
originally about the desirability of bringing NAT forward into IPv6, I =
don't
think that argument actually holds water.
>> OTOH, routers, being designed primarily to forward packets and having
>> security appliance features added as a secondary capability will, in
>> many cases, address most of these failures by passing packets which
>> would not be permitted if properly configured and/or functioning.
>=20
> Yup. What I've been saying (or implying) right along. So, in =
networks,
> or in seats, take your pick, does anyone have any deployment numbers =
on=20
> router-based firewalls vs the other sort, whatever we're calling them?
>=20
I have no idea. I think based on my observations at a variety of =
companies
it is a relatively even split, but, I will point out that the companies =
that pay
any attention to security at all do, by and large, use firewalls (my =
definition)
rather than attempt to press routers into that role. In fact, many use =
both
a router with ACLs and/or stateful inspection at the ISP handoff in =
addition
to a firewall behind it before you get to anything not intended to be on =
the
public internet.
>> Yes, they are identical and NAT makes no meaningful difference
>> to the chances that undesired packets will be forwarded in the event
>> of a catastrophic failure outside of these more common failure modes.
>=20
> I guess we're going to have to agree to disagree here; our respective=20=
> clients will decide what their opinions on that are.
>=20
I suspect so.
Owen
