[Rats] Draft-charra's use of RPC to retrieve log entries may have a potential scalability issue

["Panwei (William)" <[e-mail]>]

Hi authors,

When I reviewed the YANG module defined in this draft, I noticed that the log is retrieved by using RPC, which I think there may be a scalability issue.

The draft now defines two types of logs: bios-event-logs and ima-event-logs, both of them are designed to be retrieved by RPC. I don't know whether the bios-event-logs will have too many entries, but I think ima-event-logs do have the possibility.

The IMA measures the files in the device, calculate their hash values, and extend the hash values into the PCRs. For the ima-event-logs, it records all the files measured by IMA, including the file name, hash value, pcr-index, etc. Therefore, it's easy to see that the size of the IMA log is proportional to the number of the measured files. When there is a large number of files in the Attester that need to be measured, the number of log entries can also be significant. The problem can be much more severe in the Composite Devices, i.e., a Composite Device contains multiple Attesters, then the total amount of log entries is the sum of all files of all Attesters.

The log size is uncertain, it may consist of only a few entries, but it also may exceed tens of or even hundreds of megabytes. When the log size is large, it's inappropriate of transferring the log by messages like using NETCONF RPC. Because sending the log can take up a lot of bandwidth, and other features using the same NETCONF connection will be affected. I think other mechanisms need to be considered here, maybe using a separate protocol to transfer the log.

So what do you authors think? Is this a reasonable problem needs to be addressed?

Regards & Thanks!
Wei Pan