Re: [RFC] IMA Log Snapshotting Design Proposal - network bandwidth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 9/1/2023 5:20 PM, Tushar Sugandhi wrote:
Thanks a lot Ken for looking at the proposal, and sharing your thoughts.

On 8/30/23 11:06, Ken Goldman wrote:


On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
In addition, a large IMA log can add pressure on the network bandwidth when
the attestation client sends it to remote-attestation-service.

I would not worry too much about network bandwidth.
Our bandwidth concerns are about scaled out system.

When IMA log size increases in the range of megabytes, and when the
number of client devices increases, it makes an impact on the overall
network bandwidth.

It should not, because the client only sends new measurements. It only sends the entire list once per boot.

Does a megabyte matter in a modern network? As for overall performance,
a megabyte may take 10 msec, while the TPM quote could take 1000 msec, and verifier hash and asymmetric signature checks are also slower.



1. Every solution eventually realizes that sending the entire log each time hurts performance.  The verifier will ask the attestor, "give me everything since record n", and the number of new entries approaches zero.

Completely agreed. IMA log snapshotting (this proposed feature) is a
solution in that direction.

Does snapshotting matter? The first time, the attester sends the entire log, whether part is snapshotted or not. Same with incremental attestation.

I don't understand how snapshotting would have any affect on network traffic.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux