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

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 13 August 2020 13:04 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697873A0C04 for <rats@ietfa.amsl.com>; Thu, 13 Aug 2020 06:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iX0Uyfr6; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=OVbptB3F
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2nHtSuwt2go for <rats@ietfa.amsl.com>; Thu, 13 Aug 2020 06:04:15 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D981A3A0C03 for <rats@ietf.org>; Thu, 13 Aug 2020 06:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10821; q=dns/txt; s=iport; t=1597323854; x=1598533454; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jAN0ksF+mkHFpidrKb2x33Q4KOCxb6hbuVdHPcCVQH0=; b=iX0Uyfr64WjJernmc1xgWsxo5IntB4pb/z4n7V5eehIXRzXmlEXsHbxV lFpQ/y8pJ8sR694xVyb4nOqDRa2cghefyR5+jGz3AaTbNQesvW/00UorD Fg5ZlJyrpFQlQW29YWbeEMnbBQabM/UEoirk6YbkFDDZcyjib0aKpKLMO s=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AC//fDxE+rFftof8g+nOhCJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbXZjS9P9FzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX+elTNr3z05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9BQC7OTVf/4gNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUikoB3ArLS8sCodyA41XgQKXZYJTA1UEBwEBAQkDAQE?= =?us-ascii?q?jCgIEAQGETAKCQAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEDARIuAQE?= =?us-ascii?q?3AQQLAgEIFRAhAjAlAgQBDQ0GFII5TIF+TQMOEQ8BDqZJAoE5iGF0gTSDAQE?= =?us-ascii?q?BBYFHQYMgGIIHBwMGgTiBU4EeihAPGoFBP4ERQ4IYNT6CXAICAQGBXRWDM4I?= =?us-ascii?q?tmx+KHZBwCoJihDiCXIFPhXqLYIJ+nReFWoxZgWyIU5R3AgQCBAUCDgEBBYF?= =?us-ascii?q?qI4FXcBWDJFAXAg2OH4ElAQKCSYUUhUJ0NwIGCgEBAwl8jnABgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.76,308,1592870400"; d="p7s'?scan'208";a="800990266"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2020 13:04:13 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07DD4DHn020915 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2020 13:04:13 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:04:13 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 13 Aug 2020 08:04:12 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 13 Aug 2020 09:04:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X5BW+/PSJ98jb0oc9KvgdK2fhBf8fAPbVYcMZ0jcbbcMRc6z4kcRkEHAj22VhMxA2DsvDnAHtO+qlQlEIxq34IQQKf0hWYm7sQsFcspbWqvhCqN6BMeF/6mrjdlrZOF/kOLrHaa5+QiEalZ74Lw8W2aJ4FwDBwqZ23PpK6E9kp60qT1hZljRmlf5FSyXf3SqMcr/WSkKLIWyd3bV37ln6spFlSbhECQgnst0QUsDf3NZPMRh/2QIYX/HbV5Oyv8hzCrINJXtOzDptDMUpGV5pvDH1WqdKzsY4BqNCbqXSjcvAZ8yllJX/xmFyDhHDLjTdhH6wFNNBqXihG1xwqvgfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vuw7dKtahcIgGOD2PU6jr389/q0MG2YkjtxACT9cuws=; b=SeL7mBOWvSLSvcmDz4U6FOpEmvxvYyhTAiuXN7Tu8iBQnPtXZc+UVjxJpDFZ/8rOATc5rEtXlGI12M1aMNbfu9lRlLDTcsEhymOcQn0KxtcjZYNmY8tvnlFHDt5aRvX6GZOeBoN+IGc2LX6UZMsimFJxVUYS6CfIBJj+lFKrSMdUu2IA9b5XQ0o96NVZPPpgZJZCGiGMEqq0Bj288PPGjrRAkqHUJ0wnxHmR82U9Q+Nr0m/3oaD/0McaQKjHi/5Wc3CUxDHG2T+Ftgic2oy65cBTNa5O5LmZPBx7rBeJ04qEp3g1QE97onN5pNj5Syr2FAB8ad1JS6wZjybS7hpE7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vuw7dKtahcIgGOD2PU6jr389/q0MG2YkjtxACT9cuws=; b=OVbptB3F4NTaay0AD2yw1i5u1+9kTg65peLhTcGvGOIOvN85q7RXc/pP+35cAuaa+jdeJk1q57IuNFlIoyomccAB/QWcWmK8MhUaYuWUJ22DauBYYlmb1S5rPTl+E7QP/cWtFkm1BPnb5p5Az3FV6+WnplX9xAbXorEqP7VAJKk=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4080.namprd11.prod.outlook.com (2603:10b6:208:137::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Thu, 13 Aug 2020 13:04:11 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::fcd5:b07d:e935:8956]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::fcd5:b07d:e935:8956%7]) with mapi id 15.20.3283.016; Thu, 13 Aug 2020 13:04:11 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Panwei (William)" <william.panwei@huawei.com>, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, Dave Thaler <dthaler@microsoft.com>, "rats@ietf.org" <rats@ietf.org>
CC: "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: draft-birkholz-rats-network-device-subscription-00
Thread-Index: AdZKRjugUmuktT1iTCKR70EUNGNj/gaoi4kQAAPEPuAC/lbRQAABxp6gAAcrZWAAFvHBwA==
Date: Thu, 13 Aug 2020 13:04:11 +0000
Message-ID: <BL0PR11MB31229D0CF7D988797C0B6DC5A1430@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <BL0PR11MB31221B4EE75AADDB4685CBDEA1950@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR2101MB1027CB2B71CA83305B9608BAA3730@BL0PR2101MB1027.namprd21.prod.outlook.com> <BL0PR11MB3122F7A9111660B4D3C8B85CA1730@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR2101MB10271C5037D1F9BC826AE1F5A3420@BL0PR2101MB1027.namprd21.prod.outlook.com> <BL0PR11MB3122F0BF9EB8674F0B07FBF3A1420@BL0PR11MB3122.namprd11.prod.outlook.com> <c920579ea02d4b158ac90a9f3c744798@huawei.com>
In-Reply-To: <c920579ea02d4b158ac90a9f3c744798@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f971b891-92be-41ac-0919-08d83f895f74
x-ms-traffictypediagnostic: MN2PR11MB4080:
x-microsoft-antispam-prvs: <MN2PR11MB4080EEE6D49EA6347B91BB7DA1430@MN2PR11MB4080.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4941;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: p2z9wIlKaMv0k4Qyje3JOUe2bw1IxLHWxSt/2z9yAvVLIukb2LiyGHL0Fb2zWwsSOzOMWdhdT/uvuJrppYI/jTISl5iCRbfXnUw1vtQudwIZxzU51y43Vh19WUvYt+8W6Tq1iG9IXxQOddUkRTYdVtrylFk767GI6I8sor4yzJtBEE4QBXEwBoWz1YiQAWMcGfT5fFoHa6Ku3w+VtpBtKl7tqy+B16Wo7bdhqrEWHLxuJAqHZdqT2u9sbvqdEHM38NILBGKUB/krRmSDT51ZNdRLjBs4m+4CQwWZLiqDq1tuePohoK1kAQcg6MTq97WNQgFWyI4DnJglv95JemlSh6O9tZHUeXFvfqbLPiiiRhrSROGtI0LnX9C7vtS5CmaaxPLGagrRYNBLaFUmWBXY3Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(366004)(346002)(39860400002)(110136005)(5660300002)(8936002)(83380400001)(4326008)(478600001)(966005)(2906002)(52536014)(6506007)(55016002)(8676002)(71200400001)(7696005)(9686003)(99936003)(76116006)(86362001)(33656002)(66446008)(64756008)(66556008)(66476007)(66946007)(186003)(26005)(66616009)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 6nOBJmcY6VFXGy3gVyQr3QBm8OXnZHdEl19tpBtwzm/lp4LrhSHk/EY7cenTxSMAoUzEBm5P3gQFs1WHiG2ogHuDRbH29GRnc1NPvu/eI4mzoDwp5dM6gFOd47g/oRbFaE8kzmgoxWJVoYeRVggHNdRSJLiveeE8RJ1bvsQXQbdFTnF966iuOZz06RYep2aRKe14Df5bjkcrqGAXSWhlEj1FJPYiiCAH3TRRJRHCo0fhl/rIViOQJobKnaap6urtXhgJTl+m2n3X4QTw5JM+gCzPp9RGSSKDEZMDmu6QYkMeAel+yD+AP7+oVN3BxcSX26jVeVMMgM4Nci9N7JqTUcBTJod5xSjXztcfwlPdxWNo/5BqhcyDGq3Wt/LLCQOBY/fgncrBmiwtBIVI/9u/4rOIraZ7t94dCJ4wgoliMaQnEtcKfP2sWhBowGk7tQiHmC23+ET21yBxuUsE/Am0b0QV6BFGFWIfvahPxaZiOB6W/o9+eL3A7qBI+NmXZUdviJ+SZm8+ibTNvcknMtMi7u6Rj6c45by4XYZXQGt/ZTLXjcpqZKnvKIyzrxUXC/f0RRHqCPoDgxwDD+rR5v82AmmwfoKVOhVovtF7iGleM3KMQXZSokhNJPmWuo3fXs7pNenpP0z9cbheYJtNXfzK6Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02CC_01D67150.B13C4DD0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f971b891-92be-41ac-0919-08d83f895f74
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 13:04:11.5398 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: R/JwEKci7qapZWOTvKNDJnV6ezoZY9cGDMai3dxU0xHVKMeA/5AiO5/pDTUWhVey
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4080
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/zgCvaEgF26pOE0Xi98oIlbMTyc4>
Subject: Re: [Rats] draft-birkholz-rats-network-device-subscription-00
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 13:04:16 -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

> 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