[arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Eliot Lear <[e-mail]>]

[moving to iotops and arch-discuss, as we are now leaving the topic of LC]

Ted,

I’m going to pick on you a bit here, but just to call out a larger point, because… we are almost nowhere on this problem.

> On 4 Dec 2020, at 23:47, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Why do people buy stuff that’s not upgradeable? Probably because the manufacturer doesn’t give them a choice, and there’s no way to force the choice. The recent discussions about legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) is definitely a step in the right direction. For medical devices and medical infrastructure, this should have been required, but as far as I know still is not.


That premise is a bit too sweeping. Stuff doesn’t get upgraded for a myriad of reasons.  One is that stuff gets old.  Every manufacturer has this problem.  Cisco hardware is built to last, and it is not surprising to find equipment in the secondary market that is 15-20 years old.  If you look at a workhorse like a 7200 router that they (I wasn’t at Cisco yet) introduced in 1996, stopped selling in 2012, and only last year stopped issuing software patches for, you can still find equipment on the secondary market.  “Works like new”, $1,200 plus shipping[1].   In that span of time, just how many iPhones and Android systems have come and gone?*  What sort of eWaste problem has been created?  How long should DLink provide security updates for that frisbee that connects you to the world?  5 years? 10 years? 15 years?  Singapore didn’t answer that question, as I understand it.

And that’s in the IT market.  Now go look at the thermostat in your house.  How old is it?  In most cases, it dates back to when a house was built.  That’s the sign of a good product.  In some cases, the manufacturer may have gone out of business.    How long should an auto manufacturer support a car?  I will tell you that in general it is less than the length of time we support a router, and in some cases far less.  There are manufacturing presses that date back to the first use of electricity.  You think we have problems now?  Just wait a few years.

And then there is when and how to perform upgrades.  Apple along with a great many consumer providers has it easy when it comes to device upgrades: they can force the requirement that upgrades occur over the Internet, and that the device be rebooted.  Now try that with a transformer providing power to a hospital or a controller for an oil derrick in Alaska, where the duty cycle of a device can easily be 40 years, and the maintenance window is… oh wait.  There isn’t one.  Clearly these devices need to support in service upgrades, but even those have to be carefully thought out, tested, and planned.  And if something goes wrong, well...

My point isn’t that these upgrades shouldn’t occur.  But we do need to think differently about the whole life cycle of a system.  I’m far from the first to talk about this, nor is this insight particularly recent.  Dan Geer wrote as far back as 2012 about creating Internet kill switches[2,3].  Nor is this problem related only to security.  I’ve already mentioned the tension between security and eWaste. Cloud computing offers tremendous efficiencies, both economic and environmental, by shifting intelligence from dedicating computing to shared.  But think about what just happened this year: a number of manufacturers who use the cloud failed.  What happened to their products?  And of course Cloud computing by definition assumes Internet access, which the OT world is only beginning to allow.  After Amazon’s and Microsoft’s outages over the last several months, they may be a bit less interested.

Boiling this down, it seems to me IOT lifecycle, support models, and security models, including software ownership, open source, associated complexities, is a worthy topic to be picked up and discussed in iotops, given the life spans of some of these devices.

In answer to your direct question: yes we should be deprecating broken protocols faster than we have been.  The LC in question should have occurred at least five years ago, and it will more than justify the challenge it will give the RPC when they go to create the Updates: header ;-)

Eliot

* And don’t even get me started on Android and the vast technical deficit it and manufacturers created.  The absolutely naive and self-serving argument that only the h/w manufacturers are responsible for that mess demonstrates the limits of OSS.

[1] https://www.ebay.com/p/54829831 <https://www.ebay.com/p/54829831>
[2] https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf <https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf>
[3] https://queue.acm.org/detail.cfm?id=2479677 <https://queue.acm.org/detail.cfm?id=2479677>