Define correctly - most consumer routers will respond to a uPNP forwarding request from anywhere - what if that's a Java applet running on a compromised ad network?

So what if it is? Even if the uPnP daemon on that router is so broken that it responds to requests from the WAN that configure forwarding rules for machines on the LAN, how is this less secure than having a publicly routable IP for every one of the machines on the LAN?

To answer your question, assume that "correctly" is at least as secure as the default Windows Firewall configuration (with user-entered exceptions for video games and whatnot).

A java applet can make the request from your LAN IP, and forward whatever port to whatever other port - as well as whatever other odd features are baked into the uPnP daemon.

Anyway, the advantage for a developer is that we no longer have to do silly NAT traversals and deal with broken/incomplete NAT implementations.

Security, as always, is left as an exercise to the reader. You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.

Not having to deal with a NAT is a godsend. I know. I've had a block of publicly routable IPv6 addresses for five or eight years now.

I notice that you haven't addressed the question I asked in the first comment of mine that you responded to, and again in the second comment. I effectively asked "How is uPnP more insecure than giving the machines on your LAN publicly routable IP addresses?". I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information. Even something as weak as anecdata! I asked the question that I did in order to understand the reasoning behind that assertion.

> You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.

I don't. I'm curious, which one you'd rather deal with, and why?

> I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information.

uPnP as a spec doesn't seem to have any security (authentication/authorization) baked in. I'd find you a reference from upnp.org but they're making it difficult to search.

As an implementation - have you had a look at any firmware from consumer-level routers recently? Sorry, more anecdata. The only flaw I can remember is http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRe...

Even with a good implementation, if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like.

I know, I've accepted the risk too by keeping uPnP turned on in my network.

> You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with.

I don't want to deal with any more NAT implementations. It wasn't so long ago that the size of the tables on consumer-grade routers were small enough that BitTorrent et-al would fill the NAT & TCP tables and cause disconnections or router crashes.

NAT is a hack and we should be moving away from it.

Thanks for providing some information. I'm aware that uPnP is a large standard. Frankly, the only parts of the spec that I or any software that I run cares about are Service Discovery and IGDP.

> ...if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like.

Yes and no. The uPnP daemons that I've worked with are based on miniupnp. They all have a setting that only allows a machine to forward ports to itself. Other uPnP daemons might not have such a setting.

> I know, I've accepted the risk...

What risk? I'll ask yet again. :) How is having an automated port forwarder (even one that will forward any port to any machine on your LAN for any reason) more risky than having a publicly routable IP address assigned to each and every machine on your LAN?

If you've already answered this, I apologize for not catching on.

> NAT is a hack...

So you'd rather manage firewalls and/or running services? That's the path that I like best.

EDIT: I've read Rapid7's report on the miniupnp & etc. vulnerabilities that they found. The fun thing there is that they found implementation bugs. The issues that they raised have nothing to do with uPnP itself.

Although the ipv6 addresses are all technically globally routable, my (ISP-provided) router defaults to not routing new incoming connections through to addresses on the LAN. Outgoing TCP connections work fine. So in effect you get the same security as NAT.

That's (IMO) pretty terrible default behavior.

1) Is it easy for a somewhat technical person to change? 2) If you don't mind telling, who's your ISP?

There's an IETF standard that says IPv6 home routers should have a default deny firewall. http://tools.ietf.org/html/rfc6092#page-15 Some people are trying to get it changed: http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-...

Both of those are Informational documents, not Standards. :) Documents like this one are Standards: http://tools.ietf.org/html/rfc2616

Given the quality of MSFT's and Apple's firewalls, and the ease of use of MSFT's (I assume Apple's is easy to use, but I have no direct experience), I cannot agree that a default DENY firewall policy is a good default configuration. We'd be back in the world where consumers would need something uPnP to manage firewall rules on their router.

I can agree that refusing to route requests to things like port 445/tcp is reasonable.

It's definitely not ideal (blocking end-to-end routing defeats a lot of the point of IPv6) but i understand the security POV. It is straightforward to change, about the same complexity as forwarding a port was on IPv4 (click around in web ui for a minute or two).

The router is an AVM FritzBox 7340, the ISP is Snap (New Zealand).

I have no idea if this setting is common or not for IPv6 deployments.

Thank you very much for the information. I, too understand why that would be the default configuration. It's very good to hear that it's not a pain to change.

Do you know if you can set that FritzBox up to just act as a DSL->Ethernet bridge and pass through packets to another device that does all the routing? (Sorry if that doesn't make sense. I'm not a professional network nerd, so my terminology might be confused.)