CPE Residential IPv6 Security Poll

[Mike Jones]

On 26 September 2016 at 18:30, Tore Anderson <tore at fud.no> wrote:
> * Ted Mittelstaedt
>
>> This kind of mirrors the "default" security policy on IPv4 CPEs (since
>> those CPE's have NAT automatically turned on which creates a "block
>> in, permit out" kind of approach.) so I'm not sure why you would want
>> to default it to being different for IPv6.
>
> There are a gazillion pages out there on the Internet where you'll find
> people trying to figure out how to open ports in their router, make
> their PlayStation or Xbox online gaming Just Work instead of
> complaining about NAT problems, and so on. And this is mostly regarding
> IPv4, where we've already have a solution in the form of UPnP (a
> security nightmare in its own right).
>
> The situation is not exactly user friendly. The IPv4 NATs are making
> applications suffer and people are strugging or failing to work around
> them. We now have the opportunity to do better with IPv6, and I'm
> hoping the ISPs will carefully consider doing so, instead of just
> defaulting to whatever looks the most similar to what they've were
> forced to do for IPv4.
>
> [I say «forced», because NAT and its intrinsic «drop all inbound» policy
> came about as a way of conserving scarce IPv4 addresses, not as a
> security mechanism. This is obviously not an issue for IPv6.]
>
> So it'd be interesting to see some solid empirical data that explained
> to what extent a default-drop-inbound firewall really increases
> security, and to what extent it impairs applications and thus makes
> users unhappy.
>
> For what it's worth, the Swisscom approach seems sensible to me. At
> least if I understand it correctly, in that they by default only block
> ports associated with application protocols known to be insecure, meant
> for home network use only, etc. All other ports and protocols not on
> the blacklist are let through in both directions. As far as I know this
> has been working out fine for them.
>
> Tore

I think we are probably on the same page - the biggest problem with
the suggestion of an "advanced tab to turn it off" is that my torrent
client doesn't know how to navigate to the advanced tab on the web
interface. It also doesn't understand IPv6 uPnP.

Personally I don't see the need for blocking all inbound connections
on IPv6 as standard practice, it seems that a lot of the justification
is based on "that's how we did it with IPv4, so we need to match that
so we don't reduce security". I would counter that by asking if anyone
remembers the *reason* that IPv4 is the way it is.

No (normal) ISP decided one day that they wanted to block all inbound
traffic on IPv4. Many ISPs put a NAT in the CPE to address address
exhaustion concerns, and this also had the *unwanted* side effect of
breaking inbound connectivty. They had to develop uPnP as a hack on a
hack to reduce the problems this caused.

A residential ISP might have blocked some specific things like 445 -
but why? That example was probably because Windows had security issues
with port 445 and it was easier to block than try and patch every
system, but does that apply to the updated systems that support IPv6?
There was a time where you couldn't even get through the windows
install with an open 445, but that was a long time ago. All the ISPs I
currently have allow 445 over the public internet, and I have a few
windows systems with public IPv4 (and v6 of course) with no firewalls
in front. For the record I have no problem with this kind of targeted
blocking of specific known vulnerabilities, as long as it gets removed
when it is no longer relevant of course.

I guess the point i'm making is that people didn't make a rational
decision block all IPv4 by default, they mostly did it as a side
effect of other decisions. In that case "well that's how we do it on
IPv4" doesn't seem like much of a justification to me.

- Mike