Le 24/04/2012 10:41, David Woodhouse a écrit :
On Tue, 2012-04-24 at 00:51 +0200, Michael Markstaller wrote:
a) It's a big security risk at first as noone really knows whats going
on with IPv6 (at least on customer/user-side!)
With respect, that's complete crap. The security implications are
exactly the same with IPv6 as with Legacy IP. By *default* for the home
user, you want a connection-tracking firewall that allows outbound-only
connections.
With respect too, allow me to throw my 2 cents on this specific point.
It seems you are still considering IPv6 as a protocol that will allow
you to communicate from one human controlled device to another human
controlled device (for a large definition of human controlled device:
web sites, routers, ...). But the target of IPv6 is machine-to-machine
communication. The human factor is limited to the high end spectrum of
IPv6 use - i.e. most situations where we're using IPv4.
Of course, personnal setups are not really an issue here, because you'll
not be a very interesting target. But companies, with more and more IP
devices, will have some difficulties to cope with the security issues
that will necessarily arise.
Consider this - not that far fetched - setup:
* 10,000 IPv6-addressable light bulbs, each of them controlled by a
specialized SoC ; of course, you access the device using a wave-based
connection (probably 802.15.4 or a ZigBee-based protocol in this case).
Each batch of 1000 light bulb comes from a different vendor. That means
you have at least 10 different light bulb vendors, each one with their
own weaknesses.
* each light bulb runs a simple RT OS, and provide telnet access (because
ssh is just too heavy for light bulbs).
If you have any security issue on any one of the 100 light bulb vendor
then you put your network infrastructure at risk.
When I say that this is not far fetched, I really mean it. ZigBee is
already avalaible on SoCs [1], and those SoCs are cheaper and cheaper.
A day will come where it will be of interest to use these SoCs to
provide connectivity on devices you don't even imagine yet (coffee
machines, light bulbs, emergency panels, alarm captors... name it, put
a SoC on it, and I can assure you that you'll find some commercial
interest in doing so).
Theory makes IPv6 attractive. But - as everything - the devil is in the
details. Regarding IPv6, our first reflexion tells us "hey, that will
resolve an issue! good thing!". Problems are that many more will be
created, and we tend to forgot those. We have a duty to challenge our
assumptions: what looks better doesn't mean it's better. As of today,
IPv6 looks better, but there are tons of issues to resolve before we
can put it on production. Remember that the first IPv6 RFC is 14 years
old. From 1998 to today, most RFC dealt with resolving protocol issues
that certainly makes IPv6 better than IPv4 but that didn't exist in
IPv4 - and since IPv4 works, why one would change?
(I'm hearing a comment from the back of the room: IPv4 public address
space is full; well, not exactly: public IPv4 addresses have been
allocated by IANA to regional registrars. These registrars are still
selling IPv4 addresses to their customers - and these customers (mostly
ISP) also have a pool of still unallocated addresses - not to mention
that some organizations are making big bucks by reselling unused IPs.
There is no evidence that a pure B2B or B2C market will deplete the
IPv4 address space any time soon. The only problem with the IPv4 address
space is that it's too small for M2M communication.
Some people are naïve enough to think that NAT gives you some kind of
security. That's complete crap too.
Of course it does. Even if it's not the primary goal of NAT, it isolates
your network from the outside - not because you want to isolate it, but
because you cannot affort to spend hundreds of public IPv4 on your
corporate network. Security is not tied to NAT but still comes as a
by-product of NAT. The fact that you can punch through is what makes
NATing insufficient - but one things remain: from the outside, you
can't know what are the machine inside unless you enter. That's the
difference between being naked in your bathroom and being naked in a
public area. Sure, being naked in your bathroom doesn't mean that nobody
sees you - but to do so one must at least have a direct view on your
bathroom.
You may not agree with me, but I believe that hiding information from
a potential threat is better that providing these information. The
reason why I believe this is quite simple: unless you can assure me
that there is no bug on a specific platform, I cannot be sure that noone
will find any entry point to gain unauthorized access to this platform.
If you can prove me that the platform is 100% secure, then NATing the
platform doesn't make much sense if I can give it a public address.
This is a case of "privacy helps security" (a.k.a. security
by obscurity) that works (*). Unless you take control of one of my
machine at home (or unless I give you that information myself, for
example by visiting a web site with a particular device) it will be
very difficult for you to know how much and waht kind of devices I
own - limiting your attacks to guesses in the first place. Give me
IPv6 public addresses and all you have to do is not nmap my address
space.
There's a reason for the existence of an IPv6 NAT implementation in
Linux [2][3].
Sorry for the derailing. That were my 2 cents, you are free to discard
those arguments (or to mock them, if you feel you must do that :)).
Best regards,
-- Emmanuel Deloget
[1] https://www.google.fr/search?&q=zigbee+soc
[2] http://lwn.net/Articles/452293/
[3] http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/39974
(*) there are other cases of "security by obscurity" that works
well. One of them involves asymetric cryptography and "keep your
private key private". So, please, don't tell me it's a bad thing
:)
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
