6 ms·
> IPv4 and NAT require maintaining a lot of state at critical intermediate routers.
Far worse than the maintenance costs, NAT has has prevented (modulo a few n
> IPv4 and NAT require maintaining a lot of state at critical intermediate routers.
Far worse than the maintenance costs, NAT has has prevented (modulo a few niche environments) the development of any network software that isn't client-server. NAT is a party line[1]. Anyone that thinks NAT is useful for anything other than an address space hack (or a few other less common uses[2]): why aren't you replacing all of your household (or small business) phone numbers with a single party line? Surely you could implement a local PBX if you needed to support more than one kind of incoming call. Or what if the phone company offered a new type of line: 10% cheaper, no way to receive incoming calls. Well, sometimes you can get some incoming calls if you convince whomever actually controls the inbound phone number for your phone line to forward calls that come from certain numbers or some other criteria, like they did with the old party lines: just get people calling you at the shared number to pause after connecting and dial you per-arranged ring code[4]. (warning the phone calls might still be answered by whomever picked up first)
NAT keeps us on the client/increasingly-centralized-server model. NAT removed one of the most important benefits IP-based internetworking: no discrimination between different types of network host. Each addressable host has the power to publish - using any protocol, including new protocols - without needing an imprimatur[5]: the permission to publish from granted by some other party.
If we are very lucky, we might regain some of the lost capability with IPv6.
[preemptive response: no, NAT does NOT provide any security benefits. NAT just rewrites packet address/ports. Dropping packets is the job of the (probably stateful) firewall. Nobody wants to change that part, firewalls are important. And if you think NAT hides your internal addresses... really? Is it 192.168.x.y? Can I send GET requests to your router with a webpage full of hidden/obscured img tags with src="http{,s}://192.168.1.{1..254}/whatever?i=want"?]
[1] https://en.wikipedia.org/wiki/Party_line_%28telephony%29 https://en.wikipedia.org/wiki/Party_line_%28telephony%29
[2] Most of the time, when people say "NAT", they are only referring to the many-to-one ip masquerading similar to what is implemented in most home routers, or perhaps the "carrier grade" extensions of the same basic idea. They are probably not referring to the other flavors of NAT[3].
[3] https://tools.ietf.org/html/rfc2663#section-4.0 https://tools.ietf.org/html/rfc2663#section-4.0
[4] https://en.wikipedia.org/wiki/Party_line_%28telephony%29#Selective_ringing https://en.wikipedia.org/wiki/Party_line_%28telephony%29#Sel...
[5] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/
[preemptive response: no, NAT does NOT provide any security benefits. NAT just rewrites packet address/ports.
NAT automatically prevents attackers from scanning for and attacking listening ports on the hosts behind it. Given that those who want a service to listen to the Internet should also know enough to forward the ports, I'd say it's a pretty important security benefit and one that has greatly slowed the spread of worms.
Can I send GET requests to your router with a webpage full of hidden/obscured img tags
That requires extra action on the part of the "attackee", whereas without NAT the attacker would be able to directly connect to a port, to any machine anywhere on the Internet.
Configuring a firewall correctly is much easier than configuring NAT correctly:
Block all incoming connections by default. Have your apps/OSes on firewalled machines prompt users to allow incoming connections, and use uPnP to talk to the firewall to open the port.
With NAT, you additionally have to deal with port renumbering (what if more than one host wants to run web servers, or ssh, or VNC, etc). And because the ports are a shared resource between all hosts, you may not allow uPnP so hosts can't fight over forwarding rules.
> NAT automatically prevents attackers from scanning for and attacking listening ports on the hosts behind it.
That the firewall, not NAT. NAT on it's own - without a firewall, a very unusual configuration - will route packets to your "private" addresses if that address is in the packet's DST address field (maybe; it depends on the rules the router uses when deciding how to rout a packet, which is also not NAT). NAT is only about changing the address field. RFC 2663 even recommends that NAT should usually be "used in conjunction with firewalls to filter unwanted traffic". Unless you're referring specifically to changing the address/port fields in the packet header, you are probably referring to a stateful firewall. That's the feature that is usually responsible for dropping packets, preventing scanning of your LAN.
TL;DR - address translation (NAT), and choosing what to do with a packet (firewall, routing rules) are separate, independent features. NAT - by itself - isn't really involved in routing/firewall step. That's why it's extremely unusual to see NAT in isolation. The thing you see on e.g. most home routers is basic use of NAT combined with a simple router and (hopefully) a powerful stateful firewall.
> should also know enough to forward the ports
That's nice iff you get to decide which ports are forwarded. Good luck getting a carrier to forward ports. It isn't going to happen if you're in some parts of China behind 7 layers of NAT. Port forward in that situation would be a nightmare, assuming it was even theoretically possible to convince the 7 upstream authorities that they should forward a port to you.
However, minutia about port forwarding doesn't address my main point: that NAT limits the type of software that is developed. Are you really going to write a network app that only works if people setup port forwarding? Would business use telephone for as many purposes if phone numbers were all shared party lines?
> That requires extra action on the part of the "attackee"
That "extra action" is probably the most common vector of infection for modern malware. Ignore it at your own peril.
> route packets to your "private" addresses if that address is in the packet's DST address field
And how does such a packet make it to your router, exactly?
I disagree that it's "the firewall" doing the real work here. If things are configured properly, a firewall should be 99% irrelevant.
NAT does nothing of the sort.
Here's NAT, as implemented on a Linux machine: `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. You see that "-o wan0" there? That means the rule only applies to outbound connections, and it does nothing whatsoever to inbound connections. How can a rule that doesn't apply to inbound connections possibly do anything about the behavior of inbound connections?
On the other hand, v6 does do something about the spread of worms: networks use 64 bits of address space, so it's difficult to even find an active network host by scanning. On v4, you can find all active vulnerable hosts by just trivially scanning the entire 32-bit address space. An exhaustive search of a /64, which is just one single network, requires 0.9 ZB of traffic.
(Of course there are other ways of finding active hosts, and being obscure doesn't make the hosts in question secure -- but it _does_ render network scanning as a tool for spreading worms more or less obsolete.)
> How can a rule that doesn't apply to inbound connections possibly do anything about the behavior of inbound connections?
Outside of exotic situations, part of setting up a NAT is putting your internal hosts on a private IP range. This makes inbound packets impossible (if your ISP didn't screw up).
Even if you didn't do that, all you have to clarify is that you're replacing the existing routing rules with NAT. Mystery solved.
Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT.
And in fact, putting your internal hosts on a private IP range doesn't prevent inbound connections either. It'll limit the set of people that can do them, but anybody on your immediate upstream connection can do it just by sending packets to your router. That probably means at least your ISP and anybody who can order them to cooperate.
NAT isn't a security boundary.
(And if you replace your routing rules with NAT then everything will break, because the only thing NAT does is rewrite addresses in packets. They still need to go through the routing table to be routed.)
> Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT.
Maybe not private, but I think it's fair to say that putting them on a different IP range is expected enough that you can reasonably call it part of NAT.
> They still need to go through the routing table to be routed.
You're looking at things from a very iptables-centric view.
"Accept packets on one network interface, rewrite them, spit out the other interface if the rewrite succeeded" is a valid description of NAT that replaces all other routing.
It also prevents the "ISP screwed up" and "malicious ISP" scenarios, if your NAT is port-based. It doesn't even care if you used different IP spaces or just one.
The choice of IP range for your network is still a conceptually separate thing from the choice of whether or not to NAT outbound connections from said network. Certain choices of IP range might make NAT more or less useful to you, and thus might influence your choice, but it's still a separate thing.
Yes, I'm describing behavior from the perspective of Linux and iptables because that's what I'm familiar with... but this is the generally-understood meaning of "NAT" when used in this context, and as far as I'm aware this is how basically everything implements it. This is the behavior you'll be seeing.
Nevermind the discussion of IP range for now, I didn't explain well enough and I don't want it being a distraction.
> this is the generally-understood meaning of "NAT"
If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? I think that's a reasonable expectation, and it does not require any routing to do. And since the attack we're talking about depends on using routing to bypass the NAT, a dumb device that doesn't route is not vulnerable, and does not make your network vulnerable.
> if you think NAT hides your internal addresses
More like cgNAT makes you share the external address between many people. It gives you plausible deniability: "dear $forum admin, it's not me creating multiple accounts for trolling from the same IP address, it's the guy from the next building, I swear!" / "it's my neighbor's porn visible on https://iknowwhatyoudownload.com/en/peer/ https://iknowwhatyoudownload.com/en/peer/ not mine!"
Of course that's Not Security, that's just obscurity, but damn, it kinda does feel good :D
[I'm posting this as an attempt at general education. No personal attacks or hostility intended]
> If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right?
Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router".
However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition.
By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1]
2.2. Transparent routing
The term "transparent routing" is used throughout the document to
identify the routing functionality that a NAT device provides. This
is different from the routing functionality provided by a traditional
router device in that a traditional router routes packets within a
single address realm.
Transparent routing refers to routing a datagram between disparate
address realms, by modifying address contents in the IP header to be
valid in the address realm into which the datagram is routed.
NAT transparently[2] "routes" between address realms[3], which are defined as:
2.1. Address realm or realm
An address realm is a network domain in which the network addresses
are uniquely assigned to entities such that datagrams can be routed
to them. Routing protocols used within the network domain are
responsible for finding routes to entities given their network
addresses.
NAT accomplishes this "routing" between realms "by modifying address contents in the IP header". Changing the SRC Address field in the header is routing the packet! Any further routing decisions do not involve NAT. Once the packet's address has been changed, the actual handling of the packet is performed by the "routing protocols used within the network domain". This is also what happens to packets that were received directly into that network domain. A simple implementation might do something roughly similar to this (note: oversimplified):
| | /-----------\
| | / [Firewall] \
\ New Packet Received / | unroutable, |
\ From NIC / \ drop packet /
\-------------------/ \-----------/
| ^
v addr: unknown |
+----------------+ +-----------------+
| is DST addr in | Y | [Packet Router] |
| realm "WAN"? |--->| rules: "WAN" |
+----------------+ +-----------------+
N | addr: NAT |
v v
+----------------+ /--------------------------\
| is DST addr in | / "Route" from realm "WAN" \
| realm "LAN" | | to realm "LAN" by changing |
+----------------+ \ the IP header address /
N | | Y \--------------------------/
v | |
/-----------\ | v
/ [Firewall] \ | +---------------------------+
| Bad addr, | | | Hand off packet to be |
\ drop packet / | | routed into its new realm |
\-----------/ | +---------------------------+
v |
+-----------------+ /
| [Packet Router] |<--------------/
| rules: "LAN" |
+-----------------+
| To: the "LAN" firewall,
| other processing,
| maybe TX at the
v LAN's NIC
(...)
NAT simply hands the packet back to be routed to the LAN. Since NAT is defined as a "transparent" routing, a NAT-translated packet should be handled the same as any other packet addressed to the LAN.
> a dumb device that doesn't route is not vulnerable
If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet.
> does not make your network vulnerable.
*If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.
The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets.
[1] https://tools.ietf.org/html/rfc2663#section-2.2 https://tools.ietf.org/html/rfc2663#section-2.2
[2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.