IPv6 Firewall on CPEs - Default on or off

[Andre Tomt]

On 26. nov. 2012 10:02, Anfinsen, Ragnar wrote:
> Hi all.
>
> We are preparing to roll IPv6 out to customers with the latest and greatest CPEs we supply, which is great. We have chosen to use 6rd, due to lack of support in our access platform.

Ah, some progress. Too bad you still have to be fighting your vendors 
for native. Pretty sure I know who it is.. ;)

> However, our marketing guys have now started to question whether the IPv6 firewall function should be on or off by default. I know there are as many opinions as people on this list, but I am looking for arguments from both camps.
>
> I have my personal and clear opinion about the matter, which is off. To be able to uphold the true end to end connectivity it must obviously be off. I think the application firewall on the new OS's that support IPv6 are more than good enough, and a firewall in the CPE is redundant.
>
> However, the arguments against is that the customer is used to having a security layer on IPv4 in the CPE (NAT), and it would be bad to allow IPv6 unprotected into the customers LAN.
>
> I would really appreciate any comments and thoughts.

As already mentioned, IPv6 enabled desktop OS'es are fairly hardened and 
not very trusting of non-local traffic in most cases, are already 
mobile, and most attacks happen on higher layers on locally initiated 
connections (flash, reader, user..) anyway. So thats pro no firewall.

Also mentioned, embedded devices have a horrible, horrible track record, 
and are not really improving much. Think printers, consumer wifi 
routers, semimanaged switches and such. Combined with SLAAC not beeing 
very random (OUI space, sequential addresses within a OUI), it makes 
them easy to discover. "Lets scan this prefix for old, vulnerable HP 
printers and make them send a copy of all printouts to us!".

There is also the issue of ND neighbour table exhaustion on a lot of 
CPE, when they have to reach out to the LAN to find hosts during 
scanning sweeps. How long does your Zyxel CPE's hold up during such a scan?

So thats pro firewall.

I think however, that a good compromise can be made. If you can ensure 
randomness in the addressing of network nodes, a lot of the "protection" 
you'd get from a firewall can be regained. If you cant find the device..

I propose setting the managed address flag in the RA's issued to the 
LAN, and provide a DHCPv6 on the CPE doling out completely random 
addresses. This makes address range not really scannable, which helps 
the insecure devices. As a bonus of sorts, this also ensures the device 
have a fairly up to date networking stack, as devices not supporting 
managed addressing for IPv6 will simply sit in their little NAT'ed IPv4 
world.

Also you could in theory have a default deny filter for the prefix, 
adding an pass ACL for addresses assigned by DHCPv6 (active leases). 
That would take care of ND issue (if you have one). Of course, this 
breaks manual addressing. Is that a problem though? Anway, "only" a DoS 
issue and some vendors might have applied some magic dust to fix this 
somehow by now.

Given random addressing, I think I'm pro no firewall for consumer 
networks. At least for the time beeing.

As far as UPNP is concerned, especially the WANIPv6FirewallControl 
service, I have a guest / "here be dragons and dont blame us if they eat 
you"-network at work with it running on. It has about 200 concurrently 
active devices, and 4 months in, the WANIPv6FirewallControl has seen 
zero requests outside my own low level testing. So, with current 
applications, firewalled ipv6 does not seem to support real e2e.

-- 
André Tomt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4234 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121129/6df3b174/attachment.p7s>