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

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

Hi Michael,

> From: Michael Richardson, September 15, 2021 4:00 PM
> 
> 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-su
> > bscription/ 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.

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

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

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
> abandoned) Some even can upgrade without restarting via patching of
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
_______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats