4 ms·

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 addres

by 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...

by rlpb 15y ago

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...