Subject: Re: [Rats] Adoption call for draft-birkholz-rats-network-device-subscription-03

From: "Meiling Chen" <[email-masked]>
Date: Mon, 6 Sep 2021 09:52:53 +0800

Hi,
+1 for adoption

Best,
Meiling
 
From: Ira McDonald
Date: 2021-08-31 22:16
To: Thomas Hardjono; Ira McDonald
CC: [email-masked]; Nancy Cam-Winget \(ncamwing\)
Subject: Re: [Rats] Adoption call for draft-birkholz-rats-network-device-subscription-03
Hi,

+1 for adoption.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Aug 30, 2021 at 4:05 PM Thomas Hardjono <[email-masked]> wrote:

+1 for adoption of this draft.

--thomas

________________________________________
From: RATS [[email-masked]] on behalf of Guy Fedorkow [gfedorkow=[email-masked]]
Sent: Monday, August 30, 2021 2:12 PM
To: Nancy Cam-Winget (ncamwing); [email-masked]
Subject: Re: [Rats] Adoption call for draft-birkholz-rats-network-device-subscription-03

Hi Nancy,
  I’m on board with this adoption
Thx
/guy

Juniper Business Use Only
From: RATS <[email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Sunday, August 29, 2021 10:51 PM
To: [email-masked]
Subject: [Rats] Adoption call for draft-birkholz-rats-network-device-subscription-03

[External Email. Be cautious of content]

Hello RATs Participants,

There was prior discussion of https://datatracker.ietf.org/doc/draft-birkholz-rats-network-device-subscription/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-birkholz-rats-network-device-subscription/__;!!NEt6yMaO-gk!VaBGtiRY57QQwH7PmW8UpeIIDQpqq98TuSDhZCXLCZdoAjBMdbRx3fmhwj2FP-mS5J8$>  draft and based on feedback a new version (03) has been posted to address comments.

Please  provide your feedback as to whether you support the working group should adopt this draft as a working group document by Sept. 14 EOD.

Best, Nancy (on behalf of the RATs chairs)

_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Sep 2021 15:59:34 -0400

On 2021-08-29 10:51 p.m., Nancy Cam-Winget (ncamwing) wrote:
> Hello RATs Participants,
> 
> There was prior discussion of 
> https://datatracker.ietf.org/doc/draft-birkholz-rats-network-device-subscription/  
> draft and based on feedback a new version (03) has been posted to 
> address comments.

Hello, I have read the document.
I understand the goals, and I see how it fits into the RATS charter.
Please adopt.  I think that it builds well upon our other work. I think 
that it does not depend upon any other documents that we have not 
already adopted.  Well, maybe TUDA.
I am concerned that much of our work seems to drag out for unclear reasons.

Some comments on the document itself, which I think the WG needs to 
address in order to advance the document.

I am pleased to see that Eric Voit is also an author of RFC8639, so I 
feel confident that we are in fact using the contents correctly.
I didn't examine the YANG in detail, but I was surprised that there was 
so much of it.
I have recently been told by netmod people that much of the actual 
Enterprise/ISP use of netmod/RESTCONF  is using the XML serialization. 
While our content is more often CBOR (CWT) or JSON (JWT) encoded.
I know that I ran the CHARRA code, and I don't think it was XML encoded.
I ask because, because it seems that like there might be a mis-match 
once one tries to deploy this.

I can see that this has great utility to routers and other systems.  I'm 
a bit unclear about if a primary goal is for router to router 
attestation.  It seems like somewhere we ought to putting attestation 
results into routing protocols.  (Using passport model)

Section 4.2 concerns me.  I have routers with uptimes of 400 to 800 
days. (Do they get upgrades?  Often not, because they have been 
abandoned) Some even can upgrade without restarting via patching of 
running code.  I think that this will prove a challenge.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Sep 2021 20:03:43 +0000

Hi Michael,

> From: Michael Richardson, September 15, 2021 4:00 PM
> 
> > https://datatracker.ietf.org/doc/draft-birkholz-rats-network-device-su
> > bscription/ draft and based on feedback a new version (03) has been
> > posted to address comments.
> 
that it does
> not depend upon any other documents that we have not already adopted.
Well,
> maybe TUDA.
address
> in order to advance the document.
> 
> I am pleased to see that Eric Voit is also an author of RFC8639, so I feel
> confident that we are in fact using the contents correctly.
> I didn't examine the YANG in detail, but I was surprised that there was so
much
> of it.

The objectives of the model are modest.  What you are experiencing is how
amazingly verbose YANG is.

> I ask because, because it seems that like there might be a mis-match once
one
> tries to deploy this.

The information in YANG models can be encoded in XML, JSON, or CBOR.  This
portability was an intentional design objective.
 
> I can see that this has great utility to routers and other systems.  I'm a
bit
> unclear about if a primary goal is for router to router attestation.  It
seems like
> somewhere we ought to putting attestation results into routing protocols.
> (Using passport model)

This subscription draft now under adoption call was initially part of the
trusted path routing draft.  It was pulled out as the ability to dynamically
push newly generated Evidence from a Router is useful even when Routing
protocols are not involved.  E.g., someone might use a management interface
to remediate a compromised router directly.   The current Trusted Path
Routing draft (draft-voit-rats-trustworthy-path-routing) is a consumer of
the subscription draft, and uses the passport model as a subsystem. 
 
> Section 4.2 concerns me.  I have routers with uptimes of 400 to 800 days.
(Do
> they get upgrades?  Often not, because they have been
running
> code.  I think that this wanill prove a challenge.

Section 4.2 uses a base capability of RFC-8639 (Replay).  I would expect
that controller Verifiers need to be smart enough to only extract the
unknown set of event history which they haven't previously seen.   This is
where the statement about  <replay-start-time> comes into play.   (Note:
this is also a reason that a central Verifier also makes more sense that
having each Router / network peer parse the events which drove current PCR
values.)

Thanks,
Eric

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Sep 2021 18:54:06 -0400

Eric Voit (evoit) <[email-masked]> wrote:
    >> While our content is more often CBOR (CWT) or JSON (JWT) encoded.  I
    >> know that I ran the CHARRA code, and I don't think it was XML encoded.

    > The information in YANG models can be encoded in XML, JSON, or CBOR.
    > This portability was an intentional design objective.

yes, but if encoded as XML, then what happens to signatures?
We don't have a model for that.
What I'm asking is if we are actually doing something that the network
management people will *actually* be able to use.

    > Section 4.2 uses a base capability of RFC-8639 (Replay).  I would
    > expect that controller Verifiers need to be smart enough to only
    > extract the unknown set of event history which they haven't previously
    > seen.

Right.  So when my primary NOC burns down or floods (think Hurricane Sandy),
and I switch over to my secondary NOC, or I boot up my business continuity
DC,  how do I get that event history into the new system?

Or even a more mundane situation: I buy new NOC software.
Do I have to reboot all my routers so that they are now trusted?

    > This is where the statement about <replay-start-time> comes into
    > play.  (Note: this is also a reason that a central Verifier also makes
    > more sense that having each Router / network peer parse the events
    > which drove current PCR values.)

Mark me as skeptical that this can survive multiple hundred of day uptimes.
I think it's a hard problem.   I hate rebooting stuff.
It might be that all devices need to learn to do "hitless" upgrades every few
hundred days in order to clear the PCR.  Maybe multiple hundred day uptimes
is a problem period.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 18 Sep 2021 17:14:21 +0000

TPM NV can be used like a PCR, but it can be reset without reboot (of TPM). Possibly, the solution is to use PCRs for boot up and TPM NV for anything else that is applied post boot? Seems complicated but possible. When a hard reboot does occur possibly the stack of patches that were applied are rolled into the primary boot image and so forth?
-Ned

On 9/16/21, 3:54 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Sep 2021 15:26:46 -0400

Smith, Ned <[email-masked]> wrote:
    > TPM NV can be used like a PCR, but it can be reset without reboot (of
    > TPM). Possibly, the solution is to use PCRs for boot up and TPM NV for
    > anything else that is applied post boot? Seems complicated but
    > possible. When a hard reboot does occur possibly the stack of patches
    > that were applied are rolled into the primary boot image and so forth?

To put it differently, this is a good problem to have.
It's still a problem that needs resolution though.

Windows PCs that reboot at least once a month to apply patches probably don't
have this problem.  My Linux laptop and desktop *does* regularly go hundreds
of days without a reboot.

The routing/switching equipment at my home and work office often goes a 1000
days without a restart.  And usually, that restart is the result of power
issues.

(Is that good?  Probably not.  There are few patches, because the equipment
is abandonned/EOL far too soon by the manufacturers.   Can I afford a 3yr
replacement cycle? No. Something to think about if you care about the
integrity of the Internet as a whole, and not just the revenue stream of a
single vendor)

Years ago (now a decade...) I worked with the Brocade "Hitless" upgrade
stuff, and I think that all the major vendors have this now.  I don't know to
what extent some of them use high-availability + virtualization to do this.
(That's how I'd do it)

But, again, I'm still unclear how these mechanism will get used.
Is this Attestation going into the NOC only,  or will we see Attestation
Results being carried in routing protocols?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Sep 2021 12:55:58 +0000

Hi Michael,

> From: Michael Richardson, September 16, 2021 6:54 PM
> 
> 

The XML/JSON/CBOR encoding only applies to the information which is added as supplementary information beyond what comes out of the TPM.  I.e., the signature is the exact signature which comes out of the TPM.  It is not transcoded.   This was done so that the software stacks used to parse the TPM information are untouched no matter the wrapper encoding.
 
> and I switch over to my secondary NOC, or I boot up my business continuity DC,
> how do I get that event history into the new system?

All of the existing mechanisms for doing a one-time pull of event history still exist.  (e.g., Charra log extract RPC).   If log entries time out and are purged/lost from an endpoint, then back-end (off-device) replication of events will be needed.  Just like in Charra.
 
> Do I have to reboot all my routers so that they are now trusted?

Either you can get the logs or not.  This is true of any Remote Attestation system.  This is a shortcut however, see next point.
 
> hundred days in order to clear the PCR.  Maybe multiple hundred day uptimes is
> a problem period.

There is an easier solution here.   A Verifier can store an interim checkpoint hash calculation from log entries, lets say once a day (perhaps at 12:00:00AM).  From there, the interim entry can be used at a starting point for the hash, rather than "0000000".

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 20 Sep 2021 13:17:16 +0000

Hi Michael,
Hi Ned,

> From: Michael Richardson, September 18, 2021 3:27 PM
> 
> 
> days without a restart.  And usually, that restart is the result of power issues.
> 
> (Is that good?  Probably not.)

The routing/switching devices in the core definitely should not periodically need a reboot.  And they don't.   In my last email, I listed a way to periodically checkpoint log entries, perhaps once a day.  Do you see any reason why this should not be sufficient for a central Verifier?

> There are few patches, because the equipment
> replacement cycle? No. Something to think about if you care about the integrity
> of the Internet as a whole, and not just the revenue stream of a single vendor)
> 
> Years ago (now a decade...) I worked with the Brocade "Hitless" upgrade stuff,
> and I think that all the major vendors have this now.  I don't know to what
> extent some of them use high-availability + virtualization to do this.
> (That's how I'd do it)

And this is how it is done.
 
> Is this Attestation going into the NOC only,  or will we see Attestation Results
> being carried in routing protocols?

Because of the volume of log records, and the fact that many router vendors are not going to want to expose how they calculate the trustworthiness of a device, some form of NOC based Verifier seems a pre-requisite to me.  That said from there you can layer in the passport model and network device subscription.  This is the objective of Trusted Path Routing, and it should allow a very fresh evaluation a peer-router trustworthiness.

For a short answer on how these layers may fit together (for both NMS based Verifiers and then via Routing protocol exchange), see the earliest version of trusted path routing:
https://datatracker.ietf.org/doc/draft-voit-rats-trusted-path-routing/00/
Questions/feedback on either this initial version, or the current version built off the attestation-results draft would be great.

Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 28 Sep 2021 16:09:30 +0000

To recast the problem a bit, it isn't so much about reboot frequency as it is about update frequency. With the ability to patch on the fly, update frequency can exceed reboot frequency. As devices become increasingly more available (no reboot due to power glitches), reboot frequency becomes much lower than update frequency.

TPM designers originally expected update frequency would be about the same as reboot frequency. For example, I'm not aware of a TPM that remains powered while the rest of the system takes a power reset (with the possible exception of Intel CSME running a software TPM and a manageability stack - not trying to be an advertisement).

With update frequency crossing over that of reboot frequency, a log of updates is needed and a way to protect log integrity. A TPM isn't the only way to build a root of trust for storage (RTS), a simple RPMB (replay protected memory block) could suffice. The RPMB stores the last known good digest of the log, updates it when an update is applied. 

The bigger challenge IMHO is how to let a large Verifier community know about the updates (especially as update frequency increases). Possibly pub/sub can scale, but this is pub/sub for Endorsements/Ref-Values rather than for Evidence. (The RATS charter should be updated to include Endorsement/Ref-Values in order to keep the WG aligned within its charter). 

-Ned

On 9/20/21, 6:18 AM, "Eric Voit (evoit)" <[email-masked]> wrote:

    Hi Michael,
    Hi Ned,

    Eric