I think there are some interesting applications. Some we already know about, like monitoring HVAC systems and home temps, monitoring for water leaks, alarm systems, monitoring electrical usage, monitoring lights, monitoring people for falls or inactivity, and various other types of personal health monitoring systems. I'm sure more will be dreamed up.

As with our data and metadata in general, the key is to [be able to] keep it out of the cloud and off other people's servers. Given the motivations of industry, I think ordinary consumers buying mainstream products will find that difficult to impossible.

Wicker supports the White House effort to examine privacy in these areas, and believes that individuals need more control over the data that flows out the home. That will involve complete disclosure and an opt-out process.

"No one's data should be collected unless they voluntarily say yes," said Wicker.

Click to expand...

The 2nd statement which describes opt-in contradicts the first.

Fortunately, people have to opt-in to this to begin with by purchasing internet-able things, save for so called smart meters. Myself, I see no need for any such equipment. I already have a temperature monitor. It's called the thermostat and it works very well without needing internet. Too much of this is little more than compensating for laziness, like monitoring the lights because you were too lazy to shut them off on the way out. Spying abilities aside, people don't need more convenience. Most are too sedentary now, in body and mind. Technology like this exacerbates both.

I can already see tens of thousands of toasters used in a massive DoS attack against InfoWorld one day.

Click to expand...

What possible benefit or purpose could there be with a toaster having internet access? If they really want to do things right, start with using a bit of common sense and save internet access for things where it might serve some useful purpose.

What possible benefit or purpose could there be with a toaster having internet access? If they really want to do things right, start with using a bit of common sense and save internet access for things where it might serve some useful purpose.

Click to expand...

Well, you could program your kitchen to have meals ready on time

And actually, a British coffee pot was one of the first websites (webcam). So one could see whether there was any coffee left before walking down to the break room. Even better would be having a fresh pot brewed.

That might work for pre-packaged meals in a microwave. I wouldn't want toast that sat for several hours drying out before it got toasted. As for the break room example, which of the these 2 would apply, if not both?
1, Too lazy to walk to the break room?
2, Too lazy to make coffee if it is empty?

Looking at this IoT from a time and labor savings perspective, it's a trap that the average household just keeps falling deeper into. In order to afford all these time and labor saving devices, one or both of the members of the household works more hours, probably at a job that's even more menial and less rewarding than the jobs the devives would be doing, like cooking a good meal. Time and money may as well be one and the same. There is no free labor or free lunch. Those who fall into this trap will pay that time and labor. It'll go to their employers and to all of the middlemen who get a cut on these time and labor saving devices. In the end, they'll pay with more time and labor than they'll ever save. With the kitchen example, they'll get prepackaged, lousy tasting meals as a bonus. This is what they call progress and the wave of the future. no thanks. I'll stay in the past as much as possible.

If I were forced to choose between destroying all means of anonymity on the Internet (which would have devastating consequences for privacy and also harm security in many ways) and "tens of thousands of toasters used in a massive DoS attack against InfoWorld"... I'm definitely going with the toasters!

Seriously, if someone wants an Internet accessible toaster or hair dryer or electric toothbrush... meh. However, wherever possible these things should be behind a robust gateway device of some sort. Something that *can* be controlled, updated, equipped with strong access controls, etc. It may be best if many of these "things" were designed so that they *can't* directly access the Internet... or be directly accessed via the Internet. Design them so that they can only use and can only communicate with non-Internet-routable IP Addresses.

I'd bet that someone is poised to make a bundle from integrating internet access into everything. This got me thinking back to when electronic speed control for motors became cheap and compact. It started being into every motorized device imaginable, most of which had no need of it. Ceiling fans come to mind. Who cares if their ceiling fan rotates at exactly 120 RPM as opposed to 115 or 125 RPM? This IoT strikes me as trying to create uses for a product in places where they have no real use. The IoT devices themselves aside, someone will make a killing on the routers and hubs needed to integrate all of that junk. I also have to wonder what the effect on the human body will be, being constantly subjected to low level RF radiation coming from all around them. If its effect is in any way additive, this could be a health disaster.

I think many of these devices are being setup behind existing, and often rather primitive, [WiFi] routers. Assuming a quality SPI firewall that isn't being automatically bypassed through the likes of UPnP, you'll have some inbound protection. Assuming you're behind a NAT device, you'll have some protection against internal network information and device identifying MAC addresses leaking out. However, I think we have IPv6 scenarios to worry about and even in the IPv4 case I think it is quite rare for people to setup a (home, at least) router to provide robust outbound protection.

Arguably, we DO want to see more than a few companies making a handsome profit. Specifically, those companies which are pursuing genuinely robust solutions that are consistent with security/privacy. I don't think traditional routers will cut it, and cloud solutions certainly won't cut it. We need robust home gateways/servers. Including but not limited to all-in-one varieties that provide the functionality of a traditional [wireless] router but also include more advanced gateway/proxy/server features. Generally speaking, I don't think we want an "Internet of Things"... we want "Private Networks of Things". Including, private storage solutions and private server/gateway based interfaces to things within our homes (Internet accessible if/where that truly makes sense, which would greatly depend on an individual's situation and travel and so forth).

Walls are a wonderful thing, as are tightly controlled ingress/egress points. Sadly, many people involved in the Internet of Things, IPv6, and commercial (especially consumer grade) product design in general are deeply committed to tearing down all walls and gates. There is definitely a "lets create artificial needs/exposures and eliminate alternatives through our design" force at work here. Today's business motto seems to be "make it a service" and "drag them into our walled garden". However, from a technical POV, one can and should have their own walled garden. One that the individual owns and controls, one with strong privacy/security features, and one that they can enjoy in those ways they see fit. One may scoff at what other people want to have in their gardens. Heck, one might even scoff at other people who want to have a private garden that is off limits to solicitors and other commercial parties. Ultimately though, the choices are up to those people. What is most important is that there be a way for people to create and safely enjoy their own "gardens".

If I were forced to choose between destroying all means of anonymity on the Internet (which would have devastating consequences for privacy and also harm security in many ways) and "tens of thousands of toasters used in a massive DoS attack against InfoWorld"... I'm definitely going with the toasters!

Seriously, if someone wants an Internet accessible toaster or hair dryer or electric toothbrush... meh. However, wherever possible these things should be behind a robust gateway device of some sort. Something that *can* be controlled, updated, equipped with strong access controls, etc. It may be best if many of these "things" were designed so that they *can't* directly access the Internet... or be directly accessed via the Internet. Design them so that they can only use and can only communicate with non-Internet-routable IP Addresses.

Click to expand...

The intent, as I understand it, is for them to have IPv6 addresses. While it's possible to use IPv6 that are unroutable on the Internet, that's not the default, I think.

If we're talking about IPv6 addresses of the form that contains the device's unique hardware identifier... one that is in most cases tied to purchase records and will traverse the Internet... yes, that would be somewhat consistent with replacing anonymity with "pervasive identity". However, that solution alone would fall well short of creating a high probability of all bad guys being able to be tracked down. Other steps would need to be taken to effectively eliminate the usefulness of anonymous services and create more reliable ties to user identity. Some people would like to see the concept of "trusted paths" enforced not only at the hardware/software level but the network level as well. With some going even further to include a trusted personal-authentication step (biometrics based, as an example).

Various technical issues including protocol changes aside, I think there is some potential to make all traffic on the net traceable back to an individual and in that way attempt to address net related abuse/crime. However, that is somewhat like requiring everyone to wear non-removable personal tracking devices in an attempt to address real-world abuses/crimes. It's too extreme and involves tremendous loss of privacy. Particularly when you factor in commercial sector involvement.

If we're talking about IPv6 addresses of the form that contains the device's unique hardware identifier... one that is in most cases tied to purchase records and will traverse the Internet...

Click to expand...

Yes. But it is possible to override the default, and use some arbitrary string in place of the MAC. Right?

Also, as long as one is using dedicated virtual devices, having fixed IPv6 addresses is OK, because they incorporate MACs with no "real-world" associations. For example, I wouldn't care if this VM had an IPv6, because I only use it for mirimir stuff.

Various technical issues including protocol changes aside, I think there is some potential to make all traffic on the net traceable back to an individual and in that way attempt to address net related abuse/crime. However, that is somewhat like requiring everyone to wear non-removable personal tracking devices in an attempt to address real-world abuses/crimes. It's too extreme and involves tremendous loss of privacy. Particularly when you factor in commercial sector involvement.

Do any routers allow you to use IPv6 on the WAN side and IPv4 on the LAN side? If not, that would make a good Open Source project.

Click to expand...

As I recall from my work with pfSense 2.1, which is fully IPv6 compliant, IPv4 and IPv6 are handled differently, and can't be mixed. I don't think that it's possible to NAT IPv4 to IPv6, or even to NAT IPv6 in any way. But maybe that's a limitation with pfSense's approach to IPv6.

I think Scenario #3 is the main concern. How likely it is that someone would find themselves in such a situation, I don't know. I wouldn't expect a proper computer/OS to be the limiting factor, but here we're talking IoT devices and I'm inclined to think they are more limiting. I think I read that SLAAC is typically the default arrangement, which if true would mean that people would be using it. Not sure if some simpler devices only support SLAAC, and if so, whether they could exist on a network with other devices that are using DHCPv6 stateful for example.

Also, as long as one is using dedicated virtual devices, having fixed IPv6 addresses is OK, because they incorporate MACs with no "real-world" associations. For example, I wouldn't care if this VM had an IPv6, because I only use it for mirimir stuff.

Click to expand...

Wouldn't the most common case be one where the ISP is assigning the user a prefix (higher order bits of IP Address)? In such a scenario, even if you can and do manage the lower order bits in a way to protect against correlations (different interface identifier for each VM for example), you still have a unique/common identifier in all of the traffic to/from your connection. How easy it would be for third parties to reliably identify and leverage the prefix, I'm not sure.

IIRC, when Mirimir you go to substantial lengths to anonymize your activities/traffic and keep it isolated from your real identity. A fine thing to do, and one that should help with any such common prefixing issues, but that really isn't the "mode" that is of interest. It is the "activity/traffic is more closely tied to one's identity" mode that is of most concern. Which happens to be a mode that nearly everyone spends time in, and one which most people spend all their time in.

I think one would want to handle the prefix assignment issue like the general IPv4 NAT on single address issue... take steps to make it change periodically. Which isn't perfect, but at least it is a step that would help against some tactics.

I think Scenario #3 is the main concern. How likely it is that someone would find themselves in such a situation, I don't know. I wouldn't expect a proper computer/OS to be the limiting factor, but here we're talking IoT devices and I'm inclined to think they are more limiting. I think I read that SLAAC is typically the default arrangement, which if true would mean that people would be using it. Not sure if some simpler devices only support SLAAC, and if so, whether they could exist on a network with other devices that are using DHCPv6 stateful for example.

Click to expand...

As long as my IoT knows nothing useful about mirimir etc, I don't care.

Wouldn't the most common case be one where the ISP is assigning the user a prefix (higher order bits of IP Address)? In such a scenario, even if you can and do manage the lower order bits in a way to protect against correlations (different interface identifier for each VM for example), you still have a unique/common identifier in all of the traffic to/from your connection. How easy it would be for third parties to reliably identify and leverage the prefix, I'm not sure.

Click to expand...

In order to be useful, VMs would need IPv6 that are entirely unrelated to the Internet gateway's ISP-assigned IPv6. I would expect to make the cut at the Internet gateway. If that's not possible, we are hosed I'll look into that in pfSense 2.1, and see what's doable.

IIRC, when Mirimir you go to substantial lengths to anonymize your activities/traffic and keep it isolated from your real identity. A fine thing to do, and one that should help with any such common prefixing issues, but that really isn't the "mode" that is of interest. It is the "activity/traffic is more closely tied to one's identity" mode that is of most concern. Which happens to be a mode that nearly everyone spends time in, and one which most people spend all their time in.

Click to expand...

It's crucial that isolation/compartmentalization become the norm. That's the only way out of the panopticon(s) that is/are being created by commercial and governmental players.

I think one would want to handle the prefix assignment issue like the general IPv4 NAT on single address issue... take steps to make it change periodically. Which isn't perfect, but at least it is a step that would help against some tactics.

In order to be useful, VMs would need IPv6 that are entirely unrelated to the Internet gateway's ISP-assigned IPv6. I would expect to make the cut at the Internet gateway. If that's not possible, we are hosed I'll look into that in pfSense 2.1, and see what's doable.

Click to expand...

Perhaps it is possible in some contexts to have a single router/gateway, or multiple ones, acquire independent IPv6 info for use with different VMs. I suspect you'd pay more for it. Then again, you've probably been tolerating having different compartments utilize a common router/gateway which has but one IPv4 address. I can't imagine IPv6 preventing one from steering a particular VM's traffic out through a common router/gateway/AddressOrPrefix but off to a specific VPN or what have you.

From what I recall of IPv6 privacy extensions, I think there is some potential for surprise if you run into them unexpectedly or don't factor in how they work when setting things up. The "I setup a router/gateway rule to explicitly target X, then X was changed by privacy extension mechanism and my rule got bypassed" type situation. That might not apply to your arrangement and you'd probably be aware of it too, but figured it worth mentioning. I wonder if anything in the IoT category supports privacy extensions.

Perhaps it is possible in some contexts to have a single router/gateway, or multiple ones, acquire independent IPv6 info for use with different VMs. I suspect you'd pay more for it. Then again, you've probably been tolerating having different compartments utilize a common router/gateway which has but one IPv4 address. I can't imagine IPv6 preventing one from steering a particular VM's traffic out through a common router/gateway/AddressOrPrefix but off to a specific VPN or what have you.

Click to expand...

The concept of "hav[ing] a single router/gateway, or multiple ones, acquire independent IPv6 info for use with different VMs" is frightening. Packets exiting my first VPN's server are NATed from my ISP-assigned IPv4 address. The next VPN server in the chain NATs from the first VPN server's exit IPv4, and doesn't know my ISP-assigned IPv4. Unless VPN services did something analogous with IPv6, they would provide little anonymity.

The concept of "hav[ing] a single router/gateway, or multiple ones, acquire independent IPv6 info for use with different VMs" is frightening.

Click to expand...

Not the way I meant it. I was talking about just your gear and your public IP Address as seen in traffic that leaves your ISP provided Internet connection. Basically what I was saying is that something like this:

Not the way I meant it. I was talking about just your gear and your public IP Address as seen in traffic that leaves your ISP provided Internet connection. Basically what I was saying is that something like this:

which is better (where Address 1 and Address 2 are independent and don't share the same customer identifying IPv6 prefix for example).

Click to expand...

OK, I understand. That would disassociate traffic to two different initial VPNs. But the two ISP-assigned IPv6 addresses are easily related based on the ISP, so it's not a huge benefit.

I'm much more interested in, and concerned about, behavior of IPv6 with nested VPNs, and the VMs that establish and use the VPN links.

Consider this setup:

There are two pfSense VMs, one with a client for the outer VPN (VPN1) and the other with a client for the inner VPN (VPN2). If this were using IPv6, I would want the IPv6 addresses of all VMs, and all VPN tunnels, to be entirely unrelated to any of my ISP-assigned IPv6 addresses. I would also want all IPv6 addresses for VPN2 and associated VMs to be entirely unrelated to any IPv6 addresses for VPN1 and associated VMs. For VMs overall, the break point would be at the VirtualBox VM router. For the VPNs, the two pfSense VMs would be break points. With IPv4, "break point" is NAT. For IPv6, it might be static addressing. Or

I believe the machines within your own IPv6 network could communicate via Link-Local Addresses (LLAs), Unique Local Addresses (ULAs), and Global Unique Addresses (GUAs). An interface can have all three. I think the last two are optional. Only GUAs are meant to be routed on the Internet. I think LLAs would/should be blocked by routers. I've read that you are supposed to setup your own rules to make sure ULAs don't cross the Internet border because they are routable in general. I continue to think that a common prefix in GUAs would be a correlation risk. I read that ULAs have a Globally Unique ID portion. The idea being that companies can acquire that ID from a central registry if they want. Then, if they were to merge with another company doing so the networks could be more easily merged without conflicts. I'm inclined to consider this Global ID a correlation risk as well, even if the Global ID is a locally generated one. So depending on how you use ULAs you may want to use different Global IDs in some cases.

Perhaps you could use LLAs and/or ULAs for all of your internal communications, and just assign a GUA to the VBox Router Internet interface? That's assuming you'd still want to keep the VBox Router. I've also seen people mention Network Prefix Translation (NPT) as solution for ULA<->GUA. Since you're just mapping one prefix to another it is stateless. For that reason, and possibly others I can't recall, that particular form of translation doesn't seem to offend the IPv6 purists as much as other forms and I suspect they've allowed more NPT solutions to come into existence.

I'm not sure how I will deal with IPv6 when the time comes. As far as I can tell, that could be a while here. The last time I talked to a rep from my ISP, they haven't even started implementing it. I'm considering paying a little more for a static IP and seeing if they'd be willing to make sure that it stays IPv4.