> Op 2 nov. 2016, om 11:29 heeft Philip Homburg <[email protected]> > het volgende geschreven: > >>> So the device should have the vendor's long term TLS certicate. With possibl >> y >>> an option for the user to disable this kind of security if the device is >>> not actually connected to the internet. >> >> No, during disaster recovery the last thing you need is for ordinary people >> to be faced with strange security alerts that they've never seen before. >> (It's rather like advising people to go into the BIOS to change an option >> while the fire alarm is ringing.) >> >> Things need to just work during disaster recovery. > > Maybe I live in an unusual part of the world. But this seems very far fetched > to me for two different reasons: > > - I rate the risk of ddos attack like against Dyn way higher than a large > physical disaster. Though I have to admit that there are parts of the > world where the risk of disaster is a lot larger than here. Of course, > building code also very from country to country taking into account > disasters that may take place.
This is about "not actually connected to the internet". Could be "a large physical disaster", a "ddos attack like against Dyn" or whatever connection failure. So +1 for "Things need to just work during disaster recovery". This started with a need for somewhat accurate system time for certificate validation, right? I have to deal with stuff lacking a RTC battery. I save system time every now and then in flash. During startup, clock jumps forward to RTC when warm start occurs (main power was not interrupted) or to saved system time when a cold boot occurs. When clock is behind, it jumps forwards when NTP syncs. My certificates do not expire during "powered off, on the shelf". Teco > > - The bigger issue is that I can easily imagine partial internet access, > but that is mostly unrelated to physical disasters. I'm really curious > how you think a disaster leaves the internet broken enough that CPEs > can't phone home, but working well enough that people in the middle of > can communicate with each other. > > That said, if you think that there is a strong need for CPEs to continue to > work in a badly damaged internet, then it makes sense to make that an official > requirement. If requires specifying what this badly damaged internet really > looks like and how to test if devices can cope. > > Otherwise, CPE vendors may just silently implement what I suggest and we will > only find out during a disaster where things don't work. > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
