On Thu, 10 Sep 2020 at 21:21, Michael Richardson <[email protected]> wrote:
> On 2020-09-04 10:18 a.m., [email protected] wrote: > > Hi all, > ... > > It would be fair to include some of the limitations of the proposed > approach (e.g., IoT devices that are not maintained). > > IoT devices which never get software updates would benefit greatly from > additional protection that MUD provides. A MUD profile for such a > device would have to be created by a third party, and one way to do this > is by observation of current traffic. That could certainly include > TLS parameters observed. > There are multiple efforts in this direction, and additional > coordination is probably desirable. > That is exactly what we are working on till we get support from IoT manufacturers. > > Since the device is not getting updates, it won't be changing it's TLS > library, and so the mechanisms that are described in this document will > be even MORE effective. So I'm not sure what limitations you are > thinking about here. > > The real risk is that the device suddenly receives an update, and since > the MUD file is not from the manufacturer, that the device now sets of > alarms as the MUD file has not been updated. > To handle this scenario, the default action is not to block the TLS session but to export the network telemetry including TLS metadata for anomaly detection using machine learning techniques (similar to https://arxiv.org/pdf/1607.01639.pdf). Cheers, -Tiru > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
