Re: [Rats] Charra v03? -- Ready for YANG Doctor review?

[Guy Fedorkow <[e-mail]>]

Hi Wei Pan,
  As Eric says, the vTPM in isolation is not so hard, but it has a number of thorny questions relating the vTPM to underlying hardware.  Although I know there are some restrictions in access, but the TCG has a Virtual Platform Work Group dedicated to examining these issues and proposing solutions that balance security and flexibility.  If it's possible, it might be good to get involved with that work...
  Thanks
/guy




Juniper Business Use Only
From: Eric Voit (evoit) <[e-mail]>
Sent: Tuesday, September 29, 2020 8:16 AM
To: Panwei (William) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: Charra v03? -- Ready for YANG Doctor review?

Hi Wei Pan,

One vTPM can be handled without a volume issue.  But if we are talking lots of vTPMs, then we should examine the business purpose here.  One possibility you mention below is VNF.  A subset of the VNF is that you have vTPM serving a logical router. Certainly many vTPMs like this can increase the volume. However other significant changes will be needed before we can do a meaningful attestation of a vTPM per logical routing.  This will include:

  *   Being able to prove that a vTPM is *currently* bound to a specific physical device (potentially an x86 server.)
  *   Being able to get the attestation information about the physical device (this requires a business relationship with the hardware operator.)
  *   Proving that there is no MITM software between a virtual router and a physical device.

The Charra model is not in a position to handle the full set of virtual device requirements yet.  Nor is draft-ietf-rats-tpm-based-network-device-attest documenting these operating requirements.

As a result what we can do right now is ensure that we don't preclude what you say below.  I.e., we don't preclude "compressing the log records into a file and transferring the file by using some file transfer protocol".

I don't see anything in the current Charra which should limit sending log messages in other transports, not anything which would preclude.  Nor anything which would preclude "compressing the log records into a file and transferring the file by using some file transfer protocol".   So I don't think we are limiting future solutions with the current Charra definition.

So I think it is safe not to worry about the volume question right now.  Perhaps we should start with new drafts once the VNF topic becomes more pressing?

Thoughts?
Eric


From: Panwei, September 22, 2020 8:43 AM
Hi Eric,

For IMA and Network Equipment Boot, the log is essential for the appraisal. Because the Known Good Values are for the files and not directly for the PCRs, and the Verifier needs the log to simulate the extending processes and compare the result with the PCR values received from the Attester.
The logs have the possibility of being very large. For example, in the VNF scenario, the Attester has the ability to launch many virtual machines that have their vTPMs. If one Attester has 1024 virtual machines, each virtual machine has 1024 files to be loaded and measured, and each file has a 100bytes~ log record, then the whole log will exceed 100Mbytes.
I know to address this issue there are other ways rather than NETCONF. One simple choice I assume is that we can add an optional element 'log-file-name' in the log output RPC, when the Attester uses this element it doesn't need to send the log entries in this RPC and indicates to the Verifier that the Verifier can retrieve the log file later by some other file transfer means. In my thinking, this method is quite simple and no big change, while also increases the interoperability. But I don't know how do you feel about it?

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) [mailto:[e-mail]]
Sent: Monday, September 21, 2020 9:25 PM
To: Panwei (William) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Charra v03? -- Ready for YANG Doctor review?

Hello Wei Pan,

I am hoping this is not an issue for the Charra model for several reasons:


  *   The speed at which a TPM can do extend operations is hardware limited.  As a result I hope we don't see massively large logs.  (I am hoping that IMA logs are as large as we are ever going to get.)
  *   Code on the Attester should be able to do some pre-filtering on the types of information which might make it into a PCR.   Not everything needs to be measured.
  *   Where there does need to be *a lot* of record interpretation, there will be more need for vendor specific Verifiers.  (This is in contrast with things like Known Good Values, which can be published to many Verifiers.)
  *   There are many other ways to get large logs which are not NETCONF based.   We can always standardize choices beyond NETCONF if there is a business need for such interoperability.

Thanks,
Eric

From: Panwei (William), September 21, 2020 3:20 AM
Hi Eric, authors,

Thanks for your updating. I have one comment but not coming from your revising of the YANG model.

I have mentioned a potential scalability issue before (https://mailarchive.ietf.org/arch/msg/rats/qFq91oujxykEqBGYIW3N8ljaN68/), but unfortunately there was no more discussion about it.
The situation I'm concerned about is that when the number of log records is too many, transferring them directly using the NETCONF RPCs may be a problem because it's not so efficient. The bandwidth would be heavily consumed, and other management messages may be interfered.
I know there may be some methods to address this issue, for example, compressing the log records into a file and transferring the file by using some file transfer protocols. But these methods also need interoperability between the Attester and Verifier. So I don't know whether CHARRA draft should give a standard way to address the issue.

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) [mailto:[e-mail]]
Sent: Saturday, September 19, 2020 4:31 AM
To: [e-mail]<mailto:[e-mail]>; Panwei (William) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Charra v03? -- Ready for YANG Doctor review?

Hi Co-authors,

I just did some minor scrubbing, and added text describing  various elements of the YANG model within the mainline Charra text.

The compiled draft hasn't been merged from the pull requests<https://github.com/ietf-rats-wg/basic-yang-module/pulls> in the main repository yet.   But if/when the merging is done, it should look something like:
https://github.com/ericvoit/basic-yang-module/blob/master/draft-ietf-rats-yang-tpm-charra.txt

I believe the draft is ready for initial review by the YANG doctors.  I also believe this version is ready for posting as v03.

Any thoughts/comments/objections?

Eric