mailing list archives
Re: BCP38 tester?
From: Jay Ashworth <jra () baylink com>
Date: Mon, 1 Apr 2013 12:31:05 -0400 (EDT)
----- 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
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.
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
Re: BCP38 tester? Peter Baldridge (Apr 01)
Re: BCP38 tester? Jima (Apr 01)