4 ms·

> But NAT is way too useful and taken for granted to be removed NAT is not useful, firewalls are. NAT merely swaps an address for another in the outgoing IP p

by lloeki 15y ago

> But NAT is way too useful and taken for granted to be removed NAT is not useful, firewalls are. NAT merely swaps an address for another in the outgoing IP packet, recording the connection, and doing the inverse op on incoming packets matching the record. It's actually called IP masquerading, and it does not protect you of anything. Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT. The exact same incoming packet drop rule can readily be used with IPv6. And you can punch holes in the firewall for your internal services the same way you always did, you just don't need address swapping part anymore, nor "port forwarding", since all machines have all ports to them. In fact, the firewall stack actually gets two rules added each time you define a "port forwarding": the firewall rule to not drop the packet, and the NAT rule to forward it. Guess what forwards natively packets to the correct IPs? Routing. And that's precisely the purpose of NAT: being able to route IPs not meant to be routed in the first place, virtually extending the IP address space by having LAN machines sharing one address. The thing is, every IPv6 address is routable†, hence NAT simply has no purpose in IPv6. The only real problem is that people have been framed to think that NAT is how things work. The truth is, having no NAT anymore is a bliss. Everything is easier, from DMZ routing to authorization to abuse handling, mostly because many issues, limitations, and extra work vanish. PS: and don't start me on "NAT is good at using a single IP to connect to your machines". That's what DNS is for. † except local-scoped addresses, but those are constrained to the link, since they are automatically assigned by the machine itself, and made to provide automatic peer-to-peer link-local connectivity only. By design, having only a link-local address means you have no internet connectivity whatsoever.

Wilya 15y ago
> Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT. That's true if by 'outside' you mean 'directly on the external interface of my home router'. Because if it can indeed route my 10.something/192.168.something internal network, all the routers in between most likely can't. Maybe that's why because think NAT is safer: firewall holes are, in practice, much harder to exploit in IPv4. (Well, that, plus the firewall rules are much simpler. A few fixed ranges to drop, and be done with it. In IPv6, all has to be dynamic, and potentially configurable)
- lloeki 15y ago
  Then what's protecting you is routing, not NAT itself. 'directly on the external interface of my home router' is my ISP. Do I trust my ISP/government/whoever-bugged-in-at-the-curb enough not to add some wide route and scan 10/8,192.168/16, then jump into my LAN? In fact I've done precisely the inverse: on the outward side of a previous ISP of mine lies both a globally routable IP address and a bunch of networks of theirs on some 10/8 range, with... interesting properties. Notably that 10/8 can SSH/telnet/web-admin as root into my ISP-provided router/modem. Maybe even with some additional trick I could reach to other subscribers, hack their modem and break into their LAN. Nothing prevents you to drop outward packets whose source don't match your fixed (or DHCPv6) IP layout (e.g 2a01:whatever/126), since auto-configuration has stuff like ff:fe in the middle. Or you could leverage autoconf and drop packets from IPs not matching your list of MAC addresses. Also you can not send router advertisements nor respond to router sollicitations, or even filter out RA/RS packets, so that no autoconfiguration take place.
  - thwarted 15y ago
    Nothing prevents you to drop outward packets whose source don't match your fixed IP layout (e.g 2a01:whatever/126) In fact, you should do this to prevent spoofing attacks from being sourced from inside your network.
rlpb 15y ago
The problem is that firewalling is difficult for the same reason that NAT is difficult. For example: my SIP hardware phone has a publicly addressable IP address. I'd like to firewall it such that it can only talk to my ISP's SIP server and other parties authorised by it. How do I do this? The firewall must deep-packet inspect SIP packets to work out what point-to-point RTP traffic should be allowed, and only allow this. This difficulty does not change even in an IPv6 world. I wrote about this problem last year: http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-the-nat-problem http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-...
- agwa 15y ago
  Yes, stateful firewalls are almost as much of a blight on the Internet as NATs are. The way it's "supposed" to work is for security to be handled by the endpoints (e.g. the SIP hardware phone). But that's a totally unrealistic goal because it makes it very difficult to do centralized administration of security policies. It's also rather undesirable when mobile devices are involved (you would like to stop unauthorized traffic before it enters a wireless network where it wastes precious bandwidth and battery life). We're just going to have to live with the problem.
- lloeki 15y ago
  > The problem is that firewalling is difficult for the same reason that NAT is difficult. The problems you exemplify are not ipv4 or ipv6 problems, they are purely firewall problems. As you state in the article, people conflate NAT and firewall, but I fear you are too slightly mixing them in a way in your article (at least that's how it reads). NAT-PMP and UPnP are tools that do two things: - setup port forwarding for knowing where to NAT incoming packets - setup firewall not to drop incoming WAN packets on that port Incredibly enough, drop the NAT part, and the firewall part works just fine. Only for IPv6 it will be: - setup firewall not to drop incoming WAN packets on that port and for that destination which is just awesome since there will be no port conflict possible, and no port scarcity on the router. It would be downright trivial to extend NAT-PMP/UPnP IGD daemons (if that's not done already) to support that case, and I don't know the details but the protocols themselves might not even need to be modified, as the simple fact of communicating over IPv4/IPv6 might just be sufficient to gather all the required informations. EDIT: actually the NAT-PMP draft[0] makes mention of IPv6 EDIT: a quick search for UPnP IGD IPv6 leads to a presentation[1] about IGD:2, which includes IPv6 gateway firewall control. [0] http://files.dns-sd.org/draft-cheshire-nat-pmp.txt http://files.dns-sd.org/draft-cheshire-nat-pmp.txt [1] http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032...
there 15y ago
It's actually called IP masquerading No, it's not. This is a Linux-specific term that is used nowhere else.
- lloeki 15y ago
  Indeed, the correct phrase would have been It's actually called IP masquerading under Linux. Whatever, the point was NAT is just about proxying by forging packets with another identity and putting it back when packets comes back, and 'masquerading' conveys the idea quite nicely. I insist on forging because it is so, which makes ipsec puke since the packet changed unless you pile up yet some more hacks on top.
calloc 15y ago
There is one other one that you missed for IPv6. ULA addresses are unique local addresses that are not automatically assigned and are assigned by the administrator. They can be routed, but not on the public internet (only on your internal network (in an office, in multiple offices, datacenter, etc)). Those are not just for automatic peer-to-peer they are for assigning addresses on your network that can stay the same no matter if you change ISP's and they hand out a new /64 prefix to your network...

by lloeki 15y ago

Wilya 15y ago

> Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT. That's true if by 'outside' you mean 'directly on the external interface of my home router'. Because if it can indeed route my 10.something/192.168.something internal network, all the routers in between most likely can't. Maybe that's why because think NAT is safer: firewall holes are, in practice, much harder to exploit in IPv4. (Well, that, plus the firewall rules are much simpler. A few fixed ranges to drop, and be done with it. In IPv6, all has to be dynamic, and potentially configurable)

lloeki 15y ago
Then what's protecting you is routing, not NAT itself. 'directly on the external interface of my home router' is my ISP. Do I trust my ISP/government/whoever-bugged-in-at-the-curb enough not to add some wide route and scan 10/8,192.168/16, then jump into my LAN? In fact I've done precisely the inverse: on the outward side of a previous ISP of mine lies both a globally routable IP address and a bunch of networks of theirs on some 10/8 range, with... interesting properties. Notably that 10/8 can SSH/telnet/web-admin as root into my ISP-provided router/modem. Maybe even with some additional trick I could reach to other subscribers, hack their modem and break into their LAN. Nothing prevents you to drop outward packets whose source don't match your fixed (or DHCPv6) IP layout (e.g 2a01:whatever/126), since auto-configuration has stuff like ff:fe in the middle. Or you could leverage autoconf and drop packets from IPs not matching your list of MAC addresses. Also you can not send router advertisements nor respond to router sollicitations, or even filter out RA/RS packets, so that no autoconfiguration take place.
- thwarted 15y ago
  Nothing prevents you to drop outward packets whose source don't match your fixed IP layout (e.g 2a01:whatever/126) In fact, you should do this to prevent spoofing attacks from being sourced from inside your network.

rlpb 15y ago

The problem is that firewalling is difficult for the same reason that NAT is difficult. For example: my SIP hardware phone has a publicly addressable IP address. I'd like to firewall it such that it can only talk to my ISP's SIP server and other parties authorised by it. How do I do this? The firewall must deep-packet inspect SIP packets to work out what point-to-point RTP traffic should be allowed, and only allow this. This difficulty does not change even in an IPv6 world. I wrote about this problem last year: http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-the-nat-problem http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-...

agwa 15y ago
Yes, stateful firewalls are almost as much of a blight on the Internet as NATs are. The way it's "supposed" to work is for security to be handled by the endpoints (e.g. the SIP hardware phone). But that's a totally unrealistic goal because it makes it very difficult to do centralized administration of security policies. It's also rather undesirable when mobile devices are involved (you would like to stop unauthorized traffic before it enters a wireless network where it wastes precious bandwidth and battery life). We're just going to have to live with the problem.
lloeki 15y ago
> The problem is that firewalling is difficult for the same reason that NAT is difficult. The problems you exemplify are not ipv4 or ipv6 problems, they are purely firewall problems. As you state in the article, people conflate NAT and firewall, but I fear you are too slightly mixing them in a way in your article (at least that's how it reads). NAT-PMP and UPnP are tools that do two things: - setup port forwarding for knowing where to NAT incoming packets - setup firewall not to drop incoming WAN packets on that port Incredibly enough, drop the NAT part, and the firewall part works just fine. Only for IPv6 it will be: - setup firewall not to drop incoming WAN packets on that port and for that destination which is just awesome since there will be no port conflict possible, and no port scarcity on the router. It would be downright trivial to extend NAT-PMP/UPnP IGD daemons (if that's not done already) to support that case, and I don't know the details but the protocols themselves might not even need to be modified, as the simple fact of communicating over IPv4/IPv6 might just be sufficient to gather all the required informations. EDIT: actually the NAT-PMP draft[0] makes mention of IPv6 EDIT: a quick search for UPnP IGD IPv6 leads to a presentation[1] about IGD:2, which includes IPv6 gateway firewall control. [0] http://files.dns-sd.org/draft-cheshire-nat-pmp.txt http://files.dns-sd.org/draft-cheshire-nat-pmp.txt [1] http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032...

there 15y ago

It's actually called IP masquerading No, it's not. This is a Linux-specific term that is used nowhere else.

lloeki 15y ago
Indeed, the correct phrase would have been It's actually called IP masquerading under Linux. Whatever, the point was NAT is just about proxying by forging packets with another identity and putting it back when packets comes back, and 'masquerading' conveys the idea quite nicely. I insist on forging because it is so, which makes ipsec puke since the packet changed unless you pile up yet some more hacks on top.

calloc 15y ago

There is one other one that you missed for IPv6. ULA addresses are unique local addresses that are not automatically assigned and are assigned by the administrator. They can be routed, but not on the public internet (only on your internal network (in an office, in multiple offices, datacenter, etc)). Those are not just for automatic peer-to-peer they are for assigning addresses on your network that can stay the same no matter if you change ISP's and they hand out a new /64 prefix to your network...