Having a public address for a device in my house seems like a potential security problem - it's leaking information about my network to the outside world. And it's a dream come true for traffic-tracking.
Having a public address for a device in my house seems like a potential security problem - it's leaking information about my network to the outside world. And it's a dream come true for traffic-tracking.
The security you get from NAT is accidental (but still useful.) The problem is that it is an ugly hack and greatly restricts the types of applications that you can build on (and for) the Internet.
A good IPv6-capable home router with sane defaults can give you the same level of security as NAT, with much less complexity. You also don't need special NAT logic for applications that aren't simple request-response TCP sessions.
> it's leaking information about my network to the outside world
With sane defaults the only thing leaked is the IP address, which is already public (same as IPv4 with NAT.) Nothing about your internal network needs to be leaked.
In addition, you get a few extra benefits:
- With a /64 per network, it is almost impossible for port scanners to find you (inside a search space of 10^19 addresses.)
- The privacy extensions (which is supported by almost all operating systems) prevent you from IP-address based tracking, by assigning you a temporary address which can change frequently, and using that for external communications. This coupled with ISP-provided dynamic addresses can actually give you better privacy than IPv4.
> With sane defaults the only thing leaked is the IP address, which is already public (same as IPv4 with NAT.)
Compared to v4 NAT though, this will leak an address per device behind the firewall whereas before all these devices would not have been distinguishable.
This is why devices started to create a whole lot of temporary v6 addresses, but this causes problems for some stateful firewalls as networks grow and the amount of addresses explodes.
... just that they aren't really indistinguishable anyway. From cookies to TLS session cookies or session identifiers to specific TCP stack behaviour, it's usually quite easy to distinguish devices behind a NAT.
> This is why devices started to create a whole lot of temporary v6 addresses, but this causes problems for some stateful firewalls as networks grow and the amount of addresses explodes.
No, a stateful firewall keeps state per connection, not per address, the number of distinct addresses is of no consequence.
which is all well until it isn't:
http://blog.bimajority.org/2014/09/05/the-network-nightmare-...
A "stateful firewall" is generally a firewall that is tracking TCP and UDP packets (i.e L4 and above), so should be unconcerned with anything operating below this layer[1]. A TCP connection is a TCP connection whether running over IPv4 or IPv6.
[1]: Things become more convoluted when you have "switches" providing L3 or above functionality, but the problem referenced really is at the switching layer.
From a philosophical point of view this is extremely important. For example email used to be properly distributed. Nowadays the internet services are concentrated. For example gmail receives a big share of all emails. Amazon gets a big share of all http traffic, and so on.
In this centralised world the "client can be a server" attitude is in practice less important. NAT's are ubiquitous. Last-mile carriers don't give static IP addresses, etc.
But still, I would be much happier if the internet was truly decentralized. Even if it's not possible to decentralize all services, the internet, the addressing scheme and infrastructure just _must_ be symmetrical. Everyone connected to the net should be able to "publish" content without the need for anyones approval or infrastructure.
IPv6 addressing scheme, the removal of NAT's, brings back the democratization of the internet.
But my mum doesn't want to be a server. And I don't really want my TV being one either.
The question is not whether your mum wants to be a server, but whether she would like to use services that are only possible or are easier/cheaper to implement technically using a "server" on her machine/network.
People also don't "want a natural gas burner". People want that their home is warm and they prefer not having to shovel coal and they prefer the general lower costs of natural gas heating vs. electrical heating. So they end up buying natural gas heating systems. Not because they somehow like natural gas burners, but because that happens to be the technology that provides the comfort they like at a price they like.
And if you don't want your TV being a server, you most likely don't want it connected to the internet at all. It's not that it not being a server somehow prevents it spying on you or from being vulnerable to outside attackers.
Also, a major problem is not just the NAT itself, but the private addresses NAT tends to come with: If you have to somehow connect two networks that use the same private address space, things become incredibly hard to manage.
Also, NAT introduces major asymmetries in routing. Have you ever tried to connect to a service that's port-forwarded to an internal machine from your NAT gateway from inside the local network, for example? Well, either it will fail because pure DNAT means thet the reply packets will reach you with the wrong source address (because they don't pass through the NAT on the reverse path), so you suddenly need different configuration on the client side, depending on where you are when you try to use a service; or you have a device that does hairpin NAT in that case, which then means that the service doesn't see your actual IP address, but the address of the NAT gateway instead, which might give you confusing debug output/logging, and possibly non-working access control, and also causes your bandwidth to be severely limited by the speed of your NAT gateway, as all the traffic has to pass through the NAT gateway in order to rewrite the addresses of all packets, even though both endpoints are on the same LAN and might be able to transfer data at gigabit speed, if only there were no NAT involved.
For example, because of NAT and dynamic ip addrs allocation, my VOIP provider pretty much has to accept any ipv4 address in the world. My ISP's allocations are numerous and non-contiguous and my RFC1918 LAN address is meaningless from a security perspective. So anyone on the planet can log into my VOIP provider as if they're me, if they obtain my login info. That's kind of dumb.
However, with ipv6, with significant operational changes, it would be trivial to set up my account and firewall such that my VOIP device only talks to one specific providers /128 and my provider's account and firewall will only talk to my one very specific /128. Yeah yeah there are load balancing issues and device replacement issues such that a sane provider would operate on /64 sized networks both at their data center and my house, not individual devices. But it would be immensely more secure than ipv4, anyway.
There are other operational advantages. Currently with ipv4 companies usually don't have "an allocation" they have many, maybe dozens of little /27 here and a /28 there as they added devices. In the ipv6 world of the future companies will get a single /56 or maybe a /48 and call it good. So you get DDOSed or attacked or whatever, there's exactly one address range to block. Not 50 little ones depending on random DHCP address assignments. It'll be a much faster and simpler world. Doing egress filtering? They'll be one block to permit, thats all. Just one rule, not 75.
Unless you hardcode your IPv6 addresses, they will be generated automatically and change quite frequently. So the addresses become pretty meaningless and all you have to identify your devices really is the prefix of your network - pretty much the same amount of information as a network behind a NAT'ed IPv4 address.
In fact, as far as I remember you can actually statically assign your machines easy to remember addresses if you want but still have the machines generate temporary addresses that they use for outgoing connections, which is cool.
As for NAT - it basically gives you no extra security over a basic firewall, and just makes it really difficult to do a lot of things, such as serve content from two machines on your network on the same port. It's not the worst thing in the world, but it is a fairly sub-optimal hack and something I would really love to do away with on my networks.
I guess as/when the transition gets more widespread we'll see if NAT really was giving us any sort of security for free.
If your router is only doing NAT, they are addressable.
A packet sent to a NAT-only router destined for 10.1.2.3 will simply be routed. It may have further address re-writing applied depending on the type of NAT, but that doesn't really matter - the packet will still go through. This could be accomplished with source routing, or an attack could simply originate one hop upstream. The return packets are probably[1] unroutable, but that doesn't stop someone from simply guessing[2] you internal addresses and forging packets.
If you want to drop some class of packet - like any incoming packet destined for a local-only address - then you want a firewall, not a NAT. One drops packets, the other merely rewrites addresses. This distinction is often missed because a pure NAT-only device is rare.
> aren't fully secure
Given how easy it is to generate packets on a supposedly-"internal" network, if a device isn't secure you probably shouldn't even connect it to the network. Border-only security may be not be the worst[3] idea in network security, but it's still a bad idea that should never be relied upon.
> for free
NAT is easily the most damaging and costly problem in the entire history of the internet. It has turned a network of equal peers into a centrally controlled, cable-TV-like feudalism. What is the cost of the losing the ability to publish without the approval of a 3rd party? What kind of price tag do you put on the entire industry of network software that was never developed because it wouldn't work behind NAT?
[1] your ISP hopefully drops any packets from any address other than the IP they assigned you
[2] sending to 10.0.[0-1].[1-5] or 192.168.[0-2].[1-5] probably works often enough
[3] http://www.ranum.com/security/computer_security/editorials/d...
If you're talking about "Privacy Addresses" [0], then your statement isn't always true. If you're not using "Privacy Addresses", [1] your SLAAC or DHCPv6-assigned address remains quite stable, unless your upstream provider changes the prefix that they've assigned to your network.
> In fact, as far as I remember you can actually statically assign your machines easy to remember addresses...
You don't even have to assign addresses. SLAAC automatically creates stable addresses. "Privacy Addressing" creates random, temporary addresses. You can use both at the same time.
[0] https://tools.ietf.org/html/rfc4941
[1] And I strongly recommend that you don't. For folks who are concerned about being able to be tracked because they have a stable last 64 on every network they attach to, there are alternative methods for generating the ID used to create the SLAAC address that mix in the network prefix. [2][3] This means that -for a particular network-, you get the same last 64 every time you connect, but your last 64 is never the same on any two networks.
[2] https://tools.ietf.org/html/rfc7217
[3] On linux, dhcpcd has the "slaac private" option which enables RFC7217 address generation. "slaac hwaddr" uses the traditional, MAC address based address generation. "slaac private" (or its equivalent in other daemons) is the default setting of every Linux distro I've used in the past 6->12 months. :)
The prefix of your address may still identify your household but there isn't much tracking one can do with it, as the household may be a hotel or a coffee shop, with lots of different users. And even within the family, tracking is only useful if you can tell the difference between grandma, mum, dad and the teenagers (or even the dog who will surely soon have its own IP!). Very different targets in term of advertising.
I prefer to see my home network as just part of the internet - that way I can let guests use it without compromising my security, and I don't have to worry about vulnerabilities in my router's firmware or physical access to my network cables. IPv6 makes that very easy, because my home network really is just part of the internet.
I hope that as IPv6 takes hold this continues to be the default setup.
Most of all, it's probably an illusion. Your web browser has access to your local network, and you probably allow just about any software into your web browser. Yeah, sure, same origin policy and all that. But that doesn't help much with insecure devices or generally crappy software.
A stateful packet filter at the boundary to the public internet still would be a good idea, just without the NAT (which mostly causes complexity, which, if it has any security effect at all, makes it much harder to reason about the correctness of your firewall).