----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Ah, but did you actually test your guess on a reasonably large variety of NAT platforms?
He may not have, but now that I'm thinking (caffeine is a wonder drug), I have: I've worked on, for customers, nearly every brand of consumer router on the market, and all of them do outbound NAT the same way: Pick up a DHCP address from the carrier, and use that as the source IP on all translated outbound packets. I have never found anything for which that's *not* the default config. Upscale things like Snapgears, and routers running -WRT or Tomato, etc, can be configured to do other things, but even on those, that's the default config for outbound NAT.
It just takes 1 instance of the right platform to be in significant use for something to be different than expected.
Sure, but the question here is "is it reasonable to think that the *magnitude* of the problem is substantially reduced because consumer NAT routers are doing much of the work for us" and that answer is decidedly "yes, it is". Sure, it's egress filtering, and a bad actor can get around it, if only by *not using a router*. But a *trojan* likely cannot, and that helps us a lot too; 4-6 orders of magnitude, depending on your opinion of the penetration of consumer edge routers.
I remain unconvinced that all CPEs in all common configurations will clamp the source address to a legitimate one in all cases.
"All"? Yeah, probably not. But I think we're getting 99%, and you know what? I'll take that.
It would just be way too much luck and convenience for that to happen by coincidence.
Once in a while, you win.
Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast?
Of course there is... in some implementations you may need two NAT rules to define a 1:1; a source NAT rule, and a destination NAT rule; if you define only the Source NAT rule, you just translate the source IP address ranges selected to the translation IP address range(s) selected for outgoing connections, and new incoming connections are not translated; if you define only the DNAT rule, you translate only the WAN interface destination IP for incoming connections, and outgoing connections are not translated.
In various implementations you can have full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, symmetric NAT, and various combinations and variations (even different kinds of NAT in different directions), for each of source and destination address, with or without storage of a mapping for return traffic.
Different source or destination IP ranges or TCP/UDP ports might be NAT'ed differently or not at all.
Not all implementations allow all possible useful NAT configurations.
And the majority, by implementation count, don't allow *any* of those. They allow outbound-SNAT, and configurable inbound-DNAT, maybe. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274