Arguing against using public IP space

Jay Ashworth jra at baylink.com
Wed Nov 16 03:08:29 UTC 2011


----- Original Message -----
> From: "Mark Andrews" <marka at isc.org>

> In message
> <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja
> y Ashworth writes:
> > > >> If your firewall is not working, it should not be passing
> > > >> packets.
> > > >
> > > > And of course, things always fail just the way we want them to.
> > >
> > > Your stateful firewall is no more likely to fail open than your
> > > header-mutilating device.
> >
> > Please show your work.
> 
> Prove to me that all NAT won't pass packets not addressed directly
> to it. Show your work.

I did not *assert* that.  So I don't have to prove that. 

What I *asserted* was that inbound 1:N DNAT *reduces the probability of 
an attacker being able to target a specific inbound attack to a specific 
computer*.  QED.

> You are making assumptions about how the NAT is designed. Many
> NATs only take packets addressed to particular address ranges and
> process them though the state tables. All the rest of the packets
> are treated as normal traffic which may or may not be forwarded
> depending apon the way the base platform is configured which is
> usually as a router. Many NAT's will honour LSR.

As someone pointed out elsewhere, that's bad, but it's bad whether the box
does NAT or not; even if the internal network is unrouted public space,
that would be troublesome.

> Unless you know the internals of a NAT you cannot say whether it
> fails open or closed.

It's probably impossible to determine whether any box's response to
any failure will be pass or drop, with any reliability.  All you can
figure is probabilities.
 
> Given that most NATs only use a small set of address on the inside
> it is actually feasible to probe through a NAT using LSR. Most
> attacks don't do this as there are lots of lower hanging fruit but
> if it is a targeted attack then yes you can expect to see LSR based
> attacks which depending apon how the NAT is built may pass through
> it without even being noticed.

Someone else has already addressed "low-hanging fruit", so I won't.  I do 
concur, though: if you have specific examples of boxes which, as you allege, 
respect LSR to 1918 internal addresses, please, name and shame.
 
> Now can we put to bed that NAT provides any real security. If you
> want security add and configure a firewall. That firewall can be
> in the same box as the NAT. It can use the same state tables as
> the NAT but it is the firewall, not the NAT functionality, that
> provides the protection.

Nope; I'm afraid we still can't.  As long as you continue to strawman that
I/we are even *alleging* that NAT "provides" security (rather than 
"contributing" to it, we're just going to keep talking past each other, Mark.

As long as you keep defining protection as "one thing in one place", I'll
keep assuming you're flapping your jaws to dry your teeth. ("provides *the*
protection")

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274




More information about the NANOG mailing list