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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 12 Aug 2020 19:57:16 +0000

Hi Ned,

> From: Smith, Ned, July 28, 2020 10:54 AM
> 
> Subscription models could be topic based rather than entity based. The use case
> below suggests that a Verifier is interested in system booting events. A topic-
> based approach might allow Verifiers to subscribe to "boot image X" as the
> topic. All entities that collect a Claim for "image X" would publish the Claim to
> the field of subscribers.
> 
> Is the use of YANG to describe pub/sub limiting the ability to do topic-based
> pub/sub?

There shouldn't be any limitations inherent in doing topic-based pub/sub.   In fact, the current draft does allow for a number of pre-packaged topics as part of the event stream, as long as they are PCR based.  For example,

- a Verifier can subscribe to all 'extend' and 'quote' operations for a set of PCRs (such as PCRs 0-8).  As pre-defined set of PCRs could be considered a micro-topic.
- based on the subscription parameters requested, the Attester can filter out information for PCRs which you don't care about.  

One thing that isn't currently supported are stateful filters.  I.e., if from one event you glean that you are not running "boot image X" then throw away all subsequent events.  It is not the YANG model which prevents this, it is that a stateful event filtering language would need to be defined.

Alternatively, you could always define a new stream called "boot image X" and let people subscribe to that.  RFC8639 encourages the definition of new event streams for purposes like this.

Eric

> -Ned
> 
> On 7/28/20, 7:19 AM, "RATS on behalf of Henk Birkholz" <rats-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi Dave,
> 
>     a clarifying question:
> 
>     What exactly do you mean by the "who" in "a subscriber knows who to
>     subscribe to"?
> 
>     The I-D does not come with its own join/rendezvous/discovery capability.
>     That either comes related with YANG Push ("call home"). That would be a
>     "who" on the entity level.
> 
>     Another possibility is that you mean a YANG RPC with the "who"? That
>     would be a "who" on the management interface level.
> 
>     Or you could mean one of the Attesting Environment of a composite
>     Attester. Tha would be a "who" on the Attester level. And that is done
>     via the included data store.
> 
>     Or do you mean something I am missing here?
> 
>     Viele Grüße,
> 
>     Henk
> 
>     On 28.07.20 16:10, Dave Thaler wrote:
>     > I asked in the meeting how a subscriber knows who to subscribe to, and I
> believe the answer was
>     > that CHARRA answers that.  Well I looked in draft-ietf-rats-yang-tpm-
> charra-02 and it does not
>     > contain any mention of the subject.  I think one or the other of the two
> drafts needs to address
>     > this issue.  My preference is that it be in draft-birkholz-rats-network-device-
> subscription since
>     > that's the draft that talks about limitations like
>     >> Evidence is not streamed to an interested Verifier as soon as it is
> generated.
>     > Which certainly still applies, it's just another case... you didn't know to
> subscribe to it until
>     > after the evidence was generated when it booted.
>     >
>     > Dave
>     >
>     > -----Original Message-----
>     > From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
>     > Sent: Wednesday, June 24, 2020 9:41 AM
>     > To: [email-masked]
>     > Cc: Wei Pan <[email-masked]>; Birkholz, Henk
> <[email-masked]>
>     > Subject: [Rats] draft-birkholz-rats-network-device-subscription-00
>     >
>     > Hi All,
>     >
>     > This draft defines how to subscribe to a stream of attestation related
> Evidence on TPM-based network devices.  When subscribed, a Telemetry
> stream of verifiably fresh YANG notifications (which are generated when TPM
> PCRs are
>     > extended) are pushed to the subscriber.
>     >
>     > This draft integrates:
>     >   *  Section 5 of draft-voit-rats-trusted-path-routing-01
>     >   *  Elements of draft-xia-rats-pubsub-model
>     >
>     > Thanks!
>     >
>     > Eric, Henk, and Wei
>     >
>     >
>     > -----Original Message-----
>     > From: [email-masked] <[email-masked]>
>     > Sent: Wednesday, June 24, 2020 12:19 PM
>     > To: Eric Voit (evoit) <[email-masked]>; Wei Pan
> <[email-masked]>; Henk Birkholz
> <[email-masked]>
>     > Subject: New Version Notification for
>     > draft-birkholz-rats-network-device-subscription-00.txt
>     >
>     >
>     > A new version of I-D, draft-birkholz-rats-network-device-subscription-
> 00.txt
>     > has been successfully submitted by Eric Voit and posted to the IETF
> repository.
>     >
>     > Name:		draft-birkholz-rats-network-device-subscription
>     > Revision:	00
>     > Title:		Attestation Event Stream Subscription
>     > Document date:	2020-06-24
>     > Group:		Individual Submission
>     > Pages:		20
>     > URL:
>     >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Finternet-drafts%2Fdraft-birkholz-rats-network-device-subscription-
> 00.txt&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C25825e2a3783
> 449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637286137029115135&amp;sdata=MnEJ5ZwAh4BlTNs09fk0Vr1H39j5N
> %2BJdyBQHNJp7BdY%3D&amp;reserved=0
>     > Status:
>     >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-birkholz-rats-network-device-
> subscription%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C2582
> 5e2a3783449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47
> %7C1%7C0%7C637286137029115135&amp;sdata=qukLQaq17P4ts20nW1L%
> 2B2dB9zIM9XB9SRcscFWcOeLw%3D&amp;reserved=0
>     > Htmlized:
>     >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.i
> etf.org%2Fhtml%2Fdraft-birkholz-rats-network-device-subscription-
> 00&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C25825e2a3783449
> 230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C637286137029125095&amp;sdata=Q0TfFjrfHZU%2FKFOT3li4JG0QoBa3Vo
> %2FkHTp00T6GbZY%3D&amp;reserved=0
>     > Htmlized:
>     >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-birkholz-rats-network-device-
> subscription&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C25825e2
> a3783449230a708d8185d77f6%7C72f988bf86f141af91ab2d7cd011db47%7
> C1%7C0%7C637286137029125095&amp;sdata=RLSvdRTcWX4Gew50X2DL7t
> 2pE7N%2FA%2BKWrAVz0NhsbiA%3D&amp;reserved=0
>     >
>     >
>     > Abstract:
>     >     This document defines how to subscribe to a stream of attestation
>     >     related Evidence on TPM-based network devices.
>     >
>     >
>     >
>     >
>     > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>     >
>     > The IETF Secretariat
>     >
>     >
> 
>     _______________________________________________
>     RATS mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Dave Thaler <[email-masked]>
Date: Wed, 12 Aug 2020 21:42:42 +0000

Eric Voit wrote: 
> > I asked in the meeting how a subscriber knows who to subscribe to, and 
> > I believe the answer was that CHARRA answers that.
> 
> The answer I gave was that the problem was the same as Charra.  I believe I also said the
> problem itself is generic to any YANG based network element (I don't remember if that came out).
> Generalizing more from there, Network Operators have diverse set embedded management systems
> which include discovery, addressability, inventory, etc. of the network devices they manage.
>
> Moving back to YANG, these network management systems don't include all YANG info about a device.
> So once you have found that a device exists, the device capabilities it supports can be acquired via a variety
> of mechanisms like: 
> - NETCONF RFC 6241, Section 7 (and RFC6470)
> - YANG Library RFC 8525
>
> > Well I looked in draft-
> > ietf-rats-yang-tpm-charra-02 and it does not contain any mention of 
> > the subject.  I think one or the other of the two drafts needs to 
> > address this issue.
>
> This topic has not been within the scope of the many other YANG drafts/RFC
> which exist.   This is reasonable as there is a huge breadth of topology
> discovery protocols available and in-use for routers and switches.

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.

Dave

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 12 Aug 2020 22:58:11 +0000

Hi Dave,

> From: Dave Thaler,  August 12, 2020 5:43 PM
> 
> Eric Voit wrote:
> > > I asked in the meeting how a subscriber knows who to subscribe to,
> > > and I believe the answer was that CHARRA answers that.
> >
> > The answer I gave was that the problem was the same as Charra.  I
> > believe I also said the problem itself is generic to any YANG based
network
> element (I don't remember if that came out).
> > Generalizing more from there, Network Operators have diverse set
> > embedded management systems which include discovery, addressability,
> inventory, etc. of the network devices they manage.
> >
> > So once you have found that a device exists, the device capabilities
> > it supports can be acquired via a variety of mechanisms like:
> 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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 12 Aug 2020 23:21:16 +0000

Eric Voit wrote:
[...]
> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ 
[...]

Sounds like you're saying yes there is a referencable document.   I'm saying the answer
should be in the doc not (just) in an email message in the list archive, since the doc
talks about timing in the section with Figure 1.

Dave

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 13 Aug 2020 03:52:19 +0000

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,

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 13 Aug 2020 13:02:25 +0000

> From: Dave Thaler, August 12, 2020 7:21 PM

> > 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>
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capab

> > ilities/

> Sounds like you're saying yes there is a referencable document.   I'm
saying the

> answer

> should be in the doc not (just) in an email message in the list archive,
since the

> doc talks about timing in the section with Figure 1.

The answer is in the document.  Section 4.3.1 talks about a
<marshalling-period> which is associated with the <tpm-extend> of Figure 1.
The <marshalling-period> was also described within yesterday's thread.  Here
is its YANG definition:

    leaf marshalling-period {

      config true;

      type uint8;

      default 5;

      description

        "The maximum number of seconds between the time an event extends a
PCR,

        and the 'tpm-extend' notification which reports it to a subscribed

        Verifier.  This period allows multiple extend operations bundled

        together and handled as a group.";

    }

I have highlighted this information under Figure 1 so that readers of that
section do not have to search it out.

   o  time(eg) - Directly subsequent to the <establish-subscription>

      request, an initial response of Evidence is returned to the

      Verifier.  This includes:

...

   o  time(vg',eg') - This occurs when a PCR is extended subsequent to

      time(eg).  Within a configurable marshalling period after the

      extension (see Section 4.3.1), the following information needs to

      be pushed to the Verifier:

...

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 13 Aug 2020 13:04:11 +0000

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

> > > etc.)   I expect that most other YANG drafts/RFCs do not cover that
topic,
> > > whereas Figure 1 of
> > ilitie
> > 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"