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

["Eric Voit (evoit)" <[e-mail]>]

Hi Wei Pan,

> From: Panwei (William), August 12, 2020 11:52 PM
> 
> 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 answer tried to differentiate YANG data presented as system generation
event stream of YANG notifications, versus subscribing to changes to a YANG
datastore.  These differences are significant, and are covered in RFC-8639
vs RFC-8641.    I think Dave's response was that he simply wanted a
reference in the document, and I have now included this.

> 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.

In general I agree with all of this.  For certain attacks a Verifier might
care to investigate time(VG), time(EG), and time(NS).  But this is nothing
we need to focus upon here.

> 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.

Exactly.

> 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.

Based on Dave's request, I inserted some text under Figure 1 as he suggests
this might improve overall readability.

Eric

> 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-capab
> > ilitie
> > 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