BCP38 tester?

[jra at baylink.com (Jay Ashworth)]

----- Original Message -----
> From: "Jimmy Hess" <mysidia at 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 at 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