>> 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. - 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
