----- Original Message ----- > From: "Jimmy Hess" <[email protected]>
> 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 [email protected] 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
