Yes, security is important. What I asked was if the BACnet layer should have its own security, or if we should rely on the network security. (My router at home already gives me a 'guest' wifi with restricted access.)
And no, by adding new stuff I don't mean a new standard.
It's called an addendum.
Which, I'm surprised I overlooked, some were made especially to address the security issues: http://www.bacnet.org/Addenda/
If security really is a big issue, the LAST thing I want is give access to the secured network to my PHONE. Is your phone secure? Would you store your bitcoins on it?
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
And by supporting IP, it was also (indirectly) supporting BACnet. You just explained how services using TCP/UDP could ignore everything below... I don't understand why you don't understand it's the same thing for BACnet. Those 'official' transport layers offer you alternatives. But guess what, by supporting Ethernet and IP, BACnet can already use pretty much all the network architecture around..
BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason.
Ok, this might be the source of the confusion. Yes, the BACnet network layer needed to be defined, because at the time IP wasn't everywhere like it is today. BUT, you can easily embed this into other protocols. That's exactly how you talk about your hourglass model: BACnet devices don't care if they are connected by MS/TP, Ethernet, IP, Arcnet... They just look at the BACnet level. Just like many services look at the TCP level, not at the IP or Ethernet level.
About IPv6 for new networks, if they become required, I see no real obstacle into extending the standard for IPv6. IPv6 is itself an example of a standard changing with time. Would you prefer to throw away IP a start from scratch because IPv4 devices might not be able to communicate with IPv6?
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation(...)
But why do you consider the consumer domain to be an emerging market? For all intended purposes, you still have lighting, HVAC, access... those all already exist in bigger organizations!
All your points have contradicted my most important one.
We should never allow the situation in which someone who has been given access to the network (a guest, a child, ...) can be allowed to either control the BACnet components themselves, or install a trojan that can. By having no security built in, BACnet can be controlled by any device that has unrestricted access to the network - whether it be a compromised computer, a guest, etc. You can say that giving someone access to your wifi is some cardinal error, but people do it every day, and ignoring it would just give Apple a headache.
In an enterprise this is manageable, in a home it is not - because Apple will have bad pr from people getting their central heating hacked, but will not be able to supervise the installation themselves.
My phone is not particularly secure, no. But good sandboxing means that I can ignore the majority of network threats. If Apple programmed this in their computers as a system level program, then it would be at least as secure as (say) the keychain, which already contains enough to leave me in big trouble if it got leaked.
BACnet can use all of the network architecture around, but generally needs it to be supported in some way. For example, had BACnet used TCP - it would have been fairly trivial to get BACnet to use TLS as well, and then the security issue would have gone away.
I'm sure that all of the critical flaws with BACnet (and don't be confused, they are critical flaws) can be fixed with addendums to the standard. The problem is that then we have much BACnet compatible software that doesn't support BACnet as implemented by Apple. Again, were I Apple, I'd
- Refuse to use any BACnet device that didn't provide a minimum level of security, because it could lead to bad PR.
- Refuse to use any BACnet device that didn't operate on top of TCP at a minimum (because using TCP allows me to use (say) TLS).
- Refuse to use any BACnet device that wouldn't support both IPv4 and IPv6.
- Have to work with all the BACnet stakeholders.
- Have to make all of my software backwards compatible.
- Have to find some way of agreeing with all the stakeholders to market their Apple-compatible devices in such a way that Apple customers won't have to spend days poring over spec sheets to find out which BACnet devices are compatible with the Apple software.
BACnet is just a protocol, and a complex, bloated one - if it's flawed such that to fix it we must change it drastically, it's probably easier to just replace it. It's already clear that almost all of the devices on the market currently would not be compatible with whatever a reasonable Apple might do. Given that this might require many changes to the standard, why should they bother with all the politics when they can just do it themselves?
These flaws (believe it or not) actually negate the rest of the BACnet standard. It's a standard, yes, but it's an old one, and we can do better with the benefit of both hindsight and modern hardware. From a hardware point of view, it's probably better to use the standard - from a software or UX point of view, the standard adds nothing, but takes many things away.
As a pure point of history, BACnet became an ISO standard in 2003, work having started in 1987. TCP has been a standard since 1974, and a new standard was published in 1989. The problem for BACnet is obviously that every time a new physical transport is announced, BACnet as a standard has to add support - much effort on the part of anyone who wants to get things moving faster.
Addendums to a standard don't really hold much water, by the way. If you can just add something to a standard whenever the standard doesn't do what you want, then you lose the standardisation. Indeed, if you add anything to a standard, it ceases to be that standard (it becomes a new standard).
Your criticism of addendums to standard is warranted, except the standards we use are continuously upgraded. This week's news? HTTP/1.1. How about IPv6? HTML5? CSS3? Every time something new needs to be added, we must ask ourselves if it's worth it to start from scratch.
About security, your opinion is that the private network should be considered insecure for HVAC control. IMO someone changing the setpoint of your air conditioned is the least of your worries if someone gets in your network. But you might be right, perhaps there's a need for yet another level of security. If that's the case, then we can evaluate if we can use what's in the standard, or if we need something brand new.
These flaws (believe it or not)(...)
You can keep your snarky comments, thank you very much. A year ago I was the only one on the BACnet mailing list saying BACnet should get its shit together or a giant like Google or Apple would come and eat its lunch. I know these are flaws. I also know there are ways to patch them. The question is whether it's worth starting from scratch. You know how many Apple's engineers asked info on the BACnet mailing list? Oh right, NONE.
This smells a lot like young software developers looking at a complex software thinking they can do better... only to realize later that heck, some of these complexities were there for a reason.
Some other times, it might be 'cleaner' to start anew, but the shear effort to shift an entire industry ins't worth it. Make no mistake, it's an entire industry, and a huge one!
--
Again, were I Apple, I'd
- Refuse to use any BACnet device that didn't provide a minimum level of security, because it could lead to bad PR.
- Refuse to use any BACnet device that didn't operate on top of TCP at a minimum (because using TCP allows me to use (say) TLS).
- Refuse to use any BACnet device that wouldn't support both IPv4 and IPv6.
- Have to work with all the BACnet stakeholders.
- Have to make all of my software backwards compatible.
- Have to find some way of agreeing with all the stakeholders to market their Apple-compatible devices in such a way that Apple customers won't have to spend days poring over spec sheets to find out which BACnet devices are compatible with the Apple software.
--
In other words, make your own walled garden where you can do what you want. That's pretty much the history of Apple, unfortunately. Sad days for those yearning for more open protocols.
BACnet is just a protocol, and a complex, bloated one - if it's flawed such that to fix it we must change it drastically, it's probably easier to just replace it.
MAYBE, but I've yet to see Apple (or anyone else) opening a discussion with the HVAC industry asking what's going on, what are the needs, etc.
What I do see, is a company on the brink of disregarding a standard in 3 of the biggest standard organizations, just 'because'.
And no, by adding new stuff I don't mean a new standard.
It's called an addendum. Which, I'm surprised I overlooked, some were made especially to address the security issues: http://www.bacnet.org/Addenda/
If security really is a big issue, the LAST thing I want is give access to the secured network to my PHONE. Is your phone secure? Would you store your bitcoins on it?
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
And by supporting IP, it was also (indirectly) supporting BACnet. You just explained how services using TCP/UDP could ignore everything below... I don't understand why you don't understand it's the same thing for BACnet. Those 'official' transport layers offer you alternatives. But guess what, by supporting Ethernet and IP, BACnet can already use pretty much all the network architecture around..
BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason. Ok, this might be the source of the confusion. Yes, the BACnet network layer needed to be defined, because at the time IP wasn't everywhere like it is today. BUT, you can easily embed this into other protocols. That's exactly how you talk about your hourglass model: BACnet devices don't care if they are connected by MS/TP, Ethernet, IP, Arcnet... They just look at the BACnet level. Just like many services look at the TCP level, not at the IP or Ethernet level.
About IPv6 for new networks, if they become required, I see no real obstacle into extending the standard for IPv6. IPv6 is itself an example of a standard changing with time. Would you prefer to throw away IP a start from scratch because IPv4 devices might not be able to communicate with IPv6?
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation(...)
But why do you consider the consumer domain to be an emerging market? For all intended purposes, you still have lighting, HVAC, access... those all already exist in bigger organizations!
There's nothing new here!