RE: Arguing against using public IP space

["Chuck Church" <chuckchurch () gmail com>]

-----Original Message-----
From: Phil Regnauld [mailto:regnauld () 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