Re: [Rats] draft-birkholz-rats-network-device-subscription-00

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

Hi Eric,
Hi Dave,

I think Dave's question is that how the YANG module reflects the different time points in Figure 1, e.g., time(VG), time(EG), time(NS), and time(RG, RA).
My feeling is that time(VG), time(EG), and time(NS) don't need to be reflected. For the routers and switches, the time(VG) is usually when the devices boot, and it can be much earlier than the Evidence generation and appraisal, so usually the Verifier doesn't care about it. When the Verifier wants to establish the subscription, it generates a nonce and sends the subscription request to the Attester at the time(NS). The Attester doesn't need to know the time(NS), it just generates the Evidence according to the 'values' and nonce, and theoretically it should send back the Evidence to the Verifier immediately after generation. The Verifier can appraise the Evidence's freshness based on the nonce and the time interval between sending the subscription and receiving the Evidence, so there is usually no need for the Verifier to know the exact time(EG).
The time(RG, RA) may need to be reflected in the Attestation Result, but neither CHARRA nor this subscription draft includes this scope. I think draft-voit-rats-trustworthy-path-routing should consider this because it defines the Attestation Result YANG module.
After subscription, when a new event happens (e.g., the PCRs extends with a new value), the Attester will generate a new Evidence and send it to the Verifier. Usually the time(VG'), time(EG') and time(RG') are very close. But the "marshalling-period" leaf defined in this draft do give the Attester an opportunity to fold multiple 'values' into one Evidence to reduce the amount of notifications when multiple events happen in short succession. It reflects the max time interval between the first time(VG') and the time(EG') to the Verifier.
So for now, I think current CHARRA and RATS subscription YANG modules don't need to explicitly reflect the exact time of these time points.

Regards & Thanks!
Wei Pan

> From: Eric Voit (evoit) Thursday, August 13, 2020 6:58 AM
>
> > The topic being discussed here is about *timing* (and windows of how
> long
> > things can be out of date for,
> > etc.)   I expect that most other YANG drafts/RFCs do not cover that topic,
> > whereas Figure 1 of
> > draft-birkholz-rats-network-device-subscription specifically *does*.
> That's
> > what brings it in scope and why I believe it must be mentioned, even if
> it's by
> > reference to another document where the topic is covered.
> 
> There are a YANG nodes relevant to such timings.  For YANG datastores the
> best place to start is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilitie
> s/
> and look through definitions like:
> 
>        +--ro subscription-capabilities
>           +--ro max-nodes-per-update?               uint32
>           +--ro periodic-notifications-supported?   notification-support
>           +--ro (update-period)?
>           |  +--:(minimum-update-period)
>           |  |  +--ro minimum-update-period?        uint32
>           |  +--:(supported-update-period)
>           |     +--ro supported-update-period*      uint32
>           +--ro on-change-supported?
> notification-support
>           |       {yp:on-change}?
>           +--ro minimum-dampening-period?           uint32
>           |       {yp:on-change}?
>           +--ro supported-excluded-change-type*     union
>                   {yp:on-change}?
> 
> However it is important to note that these capabilities above are for
> reporting on changes YANG datastore nodes.  This is not the same thing as
> the placement of YANG notifications into event streams.  Therefore for this
> event subscription draft, look to the definition of the "marshalling-period"
> leaf.   This leaf attempts to define the problem from the perspective of the
> maximum amount of time from when an event extends a PCR to when the
> notification leaves the Attester.
> 
> Eric
> 
> 
> > Dave