Christian Huitema <huit...@huitema.net> wrote:
> I am not entirely convinced. This looks like keeping logs, keeping them
> online, and accessing them in real-time. That can be challenging in
> many environments. I would prefer that the draft be updated to present
Why would this be a challenge?
The MUD manager is unlikely to be a non-constrained device.
(even if it's in a home router, which I've done running code for, a few
megabytes of URL history shouldn't be a problem)
In an enterprise environment, where the could be tens of thousands of IoT
devices, the MUD manager is probably going to be in the NOC, integrated with
some SDN controller that is in charge of deploying all the resulting firewall
rules.
> the "play old URL back" issue, and then that this log-based rule be
> proposed as one of the possible solutions. If I was implementing this,
> I would probably prefer some kind of real-time mitigation.
What do you have in mind?
The MUD-URL is open to pretty much any scheme:// you can imagine.
Are you thinking about something on that side of things?
While we can invent new mechanisms on the southbound ("DHCP", "LLDP") side of
things to transmit the URL, they would require new infrastructure.
Other people (NQuiring Minds, via the NIST NCCoE IoT onboarding effort)
having been looking at continual assurance systems that would assess the
health of devices. Such a system would be collecting a set of signed
Evidence (RFC9334 sense) from the devices on a regular basis, and a
manufacturer signed MUD-URL could be provided then.
Also, draft-ietf-suit-mud also provides a stronger connection, however, since
it's in the SUIT Manifest (downward flowing, towards IoT device), rather than
in the SUIT Report (upward flowing, from IoT device to SUIT status tracker),
it has somewhat less connection to what's actually running on the device.
It does, however, provide a palette of URLs that are valid.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
