Arguing against using public IP space

Mon Nov 14 18:50:20 UTC 2011

Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.

The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable.

-----Original message-----
From: Chuck Church <chuckchurch at gmail.com>
To: 'Phil Regnauld' <regnauld at nsrc.org>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00
Subject: RE: Arguing against using public IP space

-----Original Message-----
From: Phil Regnauld [mailto:regnauld at nsrc.org]

> PAT (overload) will have ports open listening for return traffic,
> on the external IP that's being "overloaded".

> What happens if you initiate traffic directed at the RFC1918
> network itself, and send that to the MAC address of the NAT device ?

> In many cases, it just works. That's how IP forwarding works, after
> all :)
>
> inside net ----------[NAT]-----------{ext net}----[attacker]
> 192.168.0.0/24 .254 1.2.3.4 1.2.3.5

> S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4
>
> Now, on the way back *out* from the inside net, traffic from
> 192.168.0.1 back to 1.2.3.4 might get translated - it depends if
> what the NAT is programmed to do if it sees, say, a S/A packet
> with no corresponding SYN, on its way out. It might just get
> dropped. UDP would in some cases get natted, but since you
> know your destination port on 1.2.3.5, you know what to expect,
> and you can build an asymmetric connection since you control the
> attacking host.
>
> Either way, you've still injected traffic into the inside net.
>

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.
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.

Chuck