IPv6 Firewall on CPEs - Default on or off

Mark Townsley mark at townsley.net
Mon Nov 26 23:41:54 CET 2012

On Nov 26, 2012, at 11:13 PM, Nick Hilliard wrote:

> On 26/11/2012 18:38, Cameron Byrne wrote:
>> Since Vista, firewall, auto-update, IPv6 and AV are all free and on by
>> default.  And if you turn off updates or AV, it nags you.
> Anecdotally, I've noticed that people have an extraordinary ability not to
> install updates.  This is anecdata from home tech support, so don't
> particularly rely on it.  Instead, it may be better to rely on autoupdate
> percentage rates for windows / os/x / iOS / android / etc.  I don't have
> these figures to hand, but rather suspect that they are substantially less
> than 100%.
> e.g.
>> http://en.wikipedia.org/wiki/Android_%28operating_system%29#Usage_share_of_Android_versions
> This doesn't look good to me.  Similarly we can surmise from web stats that
> there are many people out there using hopelessly antiquated (but ipv6
> capable) operating systems.
>> But, please don't say  turn on a firewall without giving an explicit
>> problem the firewall solves for said user.  Please cite CVE IDs  in
>> your threat analysis / risk assessment.
> I'm not talking about just windows o/s holes here.  Any application which
> is installed and which binds to a socket will automatically offer the user
> the chance to punch a hole in their firewall and most users will not be in
> a position to make an informed decision as to the wisdom of doing this, so
> they click the "yeah, yeah, yeah, get on with it" button, whichever that
> happens to be.  So if you look at Secunia figures (and I'm not advocating
> either their products or their data collection methodology here):
> http://secunia.com/vulnerability_scanning/personal/worldmap/
> it indicates substantial problems with installed programs.  How many of
> these refer to programs which listen on sockets?  Probably quite a few.
> You asked for CVE IDs.  One of the more notorious was CVE-2012-0002, which
> was particularly bad because it was remotely exploitable, it would have
> been explicitly enabled for firewall punch-through, and it affects people
> who have a requirement for remote support.
> Another data point: compromised machines (e.g. by fly-bys) can be contacted
> directly instead of phoning home.  This means that traditional C&C servers
> can be moved to arbitrary machines, as there is no requirement for them to
> maintain a consistent IP address / hostname so that infected bots can
> connect into them.  So long as they maintain a list of affected ip
> addresses, they can connect into infected hosts directly.  IPv6 is
> potentially much worse than this because if you're not using privacy
> extensions, you may end up with the same publicly accessible ipv6 address
> for very long periods of time.  This means that the traditional arguments
> about connectivity being difficult due to sparse allocation of addresses on
> a LAN are unlikely to apply.  People will be creative about finding out and
> maintaining lists of contactable addresses.  A couple of papers have been
> written about this, but my google-fu is failing me right now.
> I put my hand straight up and say that this is not in any way a
> comprehensive analysis, but it is based on professional experience in
> dealing with desktop IT issues over a long period of time.
> My experience tells me to play it safe and do things which remove, minimise
> or at least reduce the risk to the end user.  Sticking them on an internet
> link with no line of defence between them and their attackers seems like a
> really bad idea to me.

What about something like what Eric Vyncke and I proposed here then?


It's not as far out as one might think, and casts a balance between the blunt instrument of a NAT44-like firewall (or even RFC 6092), and the notion that the user has "no line of defense". 

Bottom line, adaptive surgical strikes can be more effective and come with less collateral damage than NAPT-style carpet-bombing of yesteryore. Also, since this works on upstream as well as downstream traffic, it can detect infected machines inside your network as well as protect them from becoming infected in the first place (with limits, of course, as the network can only go so far here). This is all stuff that is applicable to IPv4 as well, though with IPv6 the potential gain is much greater since it is at least possible to remove the NAPT. 

- Mark

> Nick

More information about the ipv6-ops mailing list