From nobody Tue Jul 2 11:58:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3761206C3; Tue, 2 Jul 2019 11:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.399 X-Spam-Level: X-Spam-Status: No, score=-14.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, 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=aXaiaGHC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vNrwydBF 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 MWM-1KWSaOWO; Tue, 2 Jul 2019 11:58:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B9B1200D5; Tue, 2 Jul 2019 11:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14342; q=dns/txt; s=iport; t=1562093909; x=1563303509; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5uBxNxUOVDIq6QTiXjNmXbY4QAn0I+k4IGJNOdvHHwM=; b=aXaiaGHCChOL7BIORSDIGL5GJdBwYhUPHz84MaIcQurBbOjTHC2Ii2Z+ V5TY4eSqjQbytD4DqnQxFjj5p9FnLMcr3QatiwNraaYhsN0MBxmtTQ2uk zJfGVXkT/kdh9EX6NiL38p8n9oJBNh4IHqz0BzyquTbHrV4SC+Jssilhw o=; IronPort-PHdr: =?us-ascii?q?9a23=3AEmw4ohZ1u0b+miZuOrmooBT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavtYTY7EcBqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAACqRtd/49dJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFC9QA2pVIAQLKAqHWQOEUooMgluScIRUgS4?= =?us-ascii?q?UgRADVAkBAQEMAQEfDgIBAYRAAoIZIzQJDgEDAQEEAQECAQVtijcMhUoBAQE?= =?us-ascii?q?BAxILEBMBATcBDwIBCBEEAQEoBzIUCQgBAQQBDQUIGoMBgR1NAx0BAgyaLwK?= =?us-ascii?q?BOIhggiOCeQEBBYEyAYNcGIISCYE0AYRxhm0XgUA/gRFGgkw+gQSBXQICgSw?= =?us-ascii?q?BEQIBICsJCIJ+giaMA4dfI5Y0CQKCFoZUjUSCK2yGL44nhA2JI4c8j3ACBAI?= =?us-ascii?q?EBQIOAQEFgVA4Kj1xcBU7gjgBMwmCOINxhRSFPgFygSmMZwGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,444,1557187200"; d="scan'208,217";a="500284895" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jul 2019 18:58:01 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x62Iw1PT025563 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Jul 2019 18:58:01 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Jul 2019 13:58:00 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Jul 2019 13:57:59 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Jul 2019 13:57:59 -0500 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=OiPR1oVIrdtoYI5C8at8rmAvqGxuy0lkSL3O5jl6MZc=; b=vNrwydBFxC75EOCCIBSFb0j0RBF9ZE7ZT9NzpOZNjXVQLPhvGKEQ5obwkhFDBm8udWLSQmhN40+6on6Fs9NvdP0XZrATGgamaR3aCklB5nzFQFTG+mxDRicbb0CX4kjmRmA8ihqLVYvB3yMp42ewz7y+f2UFDan9mR0PRDWj0do= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB3577.namprd11.prod.outlook.com (20.178.229.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.15; Tue, 2 Jul 2019 18:57:58 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::496e:2b30:2186:fb23]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::496e:2b30:2186:fb23%7]) with mapi id 15.20.2032.019; Tue, 2 Jul 2019 18:57:58 +0000 From: "Owen Friel (ofriel)" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wFAVG6Q Date: Tue, 2 Jul 2019 18:57:58 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6df506f-c510-427c-ca67-08d6ff1f332f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB3577; x-ms-traffictypediagnostic: DM6PR11MB3577: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(199004)(189003)(6246003)(74316002)(4326008)(606006)(71200400001)(71190400001)(6506007)(25786009)(53546011)(81156014)(52536014)(99286004)(8676002)(966005)(229853002)(68736007)(7696005)(7736002)(5660300002)(6436002)(66066001)(81166006)(9686003)(236005)(53936002)(55016002)(76176011)(54896002)(6306002)(33656002)(6116002)(11346002)(3846002)(790700001)(446003)(486006)(476003)(66556008)(64756008)(66446008)(26005)(66476007)(76116006)(102836004)(73956011)(66946007)(9326002)(316002)(86362001)(2501003)(110136005)(14444005)(8936002)(14454004)(256004)(478600001)(2906002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3577; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: D5+LGcqIkY72M5AqnBe5xYao2H1gMGJ7qKOuZF+Ip78GIkZ+Dxaaysd4kzUYVPqIaEshLgBb3enwsxBHsQgX+bB7VgVcyHdS5uQOG81Pp1oS+tnL/SHnhm7LCOPLZuHyAIS4H30BQ9UoVUYqIBW7bWfTwnTi2xknRG5CfXM/+O7i3+Ax0isv4fFQmdcgBpa5pS+wgs+ae29tsz0eCGhUIkpEA3bW+StiEo+t6+7yJGVsm66suWmHjOSSmZ9coapmfwTv+kKg3pxqP9YTOuWpTCNlzZIZaqNMgJmAhet1Zk31+SNvYp3QQ90OHjzz5Dam9o7Zm3ggQ0k9fsZxOZoR7atlv/AinFUGgElhLxfDmzIlEQaK8o3U53at2MFr2h5TRWCKQhIoujoeVMDmAORW6AVK5R8PNbttsvon170FKFU= Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3385B6990309DA4312DDA5F0DBF80DM6PR11MB3385namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f6df506f-c510-427c-ca67-08d6ff1f332f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 18:57:58.5494 (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: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3577 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 18:58:32 -0000 --_000_DM6PR11MB3385B6990309DA4312DDA5F0DBF80DM6PR11MB3385namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like a time slot for: Name of time slot: BRSKI / Afternoon session I Name of draft(s): draft-friel-acme-integrations Time requested: 10 mins Presenter name(s): Owen Friel And the draft covers how to potentially integrate BRSKI with ACME. Owen From: Anima On Behalf Of Sheng Jiang Sent: 26 June 2019 10:59 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs' email. Please note that ema= il to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_DM6PR11MB3385B6990309DA4312DDA5F0DBF80DM6PR11MB3385namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like a time slot for:

 

Name of time slot: BRSKI / Afternoon session I

Name of draft(s): draft-friel-acme-integrations

Time requested: 10 mins

Presenter name(s): Owen Friel

 

And the draft covers how to potentially integrate BRSKI with ACME.<= o:p>

 

Owen

 

 

From:= Anima <anima-bounces@ie= tf.org> On Behalf Of Sheng Jiang
Sent: 26 June 2019 10:59
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

 

Hi, all anima,
 
We have been allocated two sessions of 2 + 1.5 hour for the A=
NIMA WG meeting for IETF-105 (Montreal) - Tuesday Morning session I and Aft=
ernoon session I. We are now starting to collect agenda items for the sessi=
ons. Please send your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org and both chairs=
’ email. Please note that email to a single chair may cause single fa=
ilure.
 
For this coming meeting, we would like have the 1.5 hour session =
for BRSHI and Voucher relevant topics and the 2 hour session for the others=
. As normal, the priority among these non-charter work items would be: thes=
e that have active discussion in mail list, then these have submitted draft=
s, and topics without drafts.
 
As you may observed, so far, our re-charter progress still not in=
 the procedure. Until we have the new charter in the place by the IETF 105 =
week, we still not be able to adopt any new work.
 
Please send us (anima-chairs at ietf.org<https://ietf.org=
/>;) requests for time slot by July 11th, Thursday and includ=
e:
 
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
 
More details about the IETF 105, Montreal can be found at:
 
https://www.ie=
tf.org/how/meetings/105/
 
Again, presenters and draft authors please invoke active discussi=
ons in the ANIMA list. Mail list is a very good place to discuss and reach =
consensus on technical issues.
 
Best regards,
 
Sheng
--_000_DM6PR11MB3385B6990309DA4312DDA5F0DBF80DM6PR11MB3385namp_-- From nobody Tue Jul 2 12:04:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197F21206E0 for ; Tue, 2 Jul 2019 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=h+ZUEC6k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xGEykkdk 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 N3qarnBgJ8Oq for ; Tue, 2 Jul 2019 12:04:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED681200D5 for ; Tue, 2 Jul 2019 12:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3080; q=dns/txt; s=iport; t=1562094279; x=1563303879; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D1Ehrq9H8pjFJiwI9RI1QhvcWmZWy0yaILIJlQkrRIU=; b=h+ZUEC6kfSHz9s81HsXN5rHOTHiwj0prtVYRnM5ktxUNRris4e2pq0dm W9GVxhhUv6Gx7qgHMu/PKom9zBWboF9BDhkHtAYhdEan503efUnIdOPfL tbYlXYSqFr3DI3dHN5xA36M/Ac6Lw2+iZ9qiaJdVm0DlRagrEhHHuf5e2 I=; IronPort-PHdr: =?us-ascii?q?9a23=3A+Ny7uBzEF/NA6JLXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuCB1f6IfrCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAABQqhtd/5FdJa1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFDUANqVSAECygKhBKDRwOEUooMgluXRIEugSQDVAk?= =?us-ascii?q?BAQEMAQElCAIBAYRAAheCAiM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBAQMSERE?= =?us-ascii?q?MAQE1AwsEAgEIEQQBAQMCJgICAjAVBgEBBQMCBAESCBqDAYFqAx0BAgyaJQK?= =?us-ascii?q?BOIhgcYEygnkBAQWBNgIOQYMIGIISCYEMKAGLXheBQD+BEUaCTD6CYQEBAgE?= =?us-ascii?q?BFoFJgwgygiaOZoUfljQJAoIWhlSNRIIrbIYvjieNMIc8j3ACBAIEBQIOAQE?= =?us-ascii?q?FgVA4gVhwFRqDDQmCOINxhRSFP3IBgSiMZwGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,444,1557187200"; d="scan'208";a="590307707" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jul 2019 19:04:38 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x62J4cBZ029244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Jul 2019 19:04:38 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Jul 2019 14:04:37 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Jul 2019 15:04:36 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Jul 2019 14:04:36 -0500 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=D1Ehrq9H8pjFJiwI9RI1QhvcWmZWy0yaILIJlQkrRIU=; b=xGEykkdkUOIESFklbZjnglobF2LuO69a5BNGjVL2p4TpW/Z20IRvNRRn22PxIggY3Hpk83/iwNQWiLg2Ag6p4Dg97A/xGYf+NYOMnRKLzjaN5bUO9gO/59wJgLIHsyetzTfZOuo3mQgvuuygP/LxDtm5KGvI/7yT0KZIdWW3iUU= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB2553.namprd11.prod.outlook.com (20.176.95.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Tue, 2 Jul 2019 19:04:35 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::496e:2b30:2186:fb23]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::496e:2b30:2186:fb23%7]) with mapi id 15.20.2032.019; Tue, 2 Jul 2019 19:04:35 +0000 From: "Owen Friel (ofriel)" To: "anima@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: New Version Notification for draft-friel-acme-integrations-01.txt Thread-Index: AQHVMQb4X6tqrYd/KEe6IqDPJ/uJ2Ka3rneA Date: Tue, 2 Jul 2019 19:04:35 +0000 Message-ID: References: <156209339375.23780.16389385862360970000.idtracker@ietfa.amsl.com> In-Reply-To: <156209339375.23780.16389385862360970000.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5bbcd0a8-bcab-44b4-149f-08d6ff201f9d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB2553; x-ms-traffictypediagnostic: DM6PR11MB2553: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(199004)(189003)(13464003)(476003)(5660300002)(68736007)(33656002)(86362001)(7736002)(66066001)(6436002)(53546011)(26005)(446003)(66446008)(64756008)(73956011)(76176011)(478600001)(316002)(55016002)(6306002)(8936002)(99286004)(110136005)(25786009)(14454004)(966005)(14444005)(71190400001)(6506007)(66946007)(52536014)(229853002)(8676002)(66556008)(186003)(102836004)(2906002)(2473003)(9686003)(256004)(66476007)(305945005)(11346002)(2501003)(76116006)(74316002)(81166006)(15650500001)(486006)(66574012)(81156014)(7696005)(3846002)(71200400001)(6116002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2553; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KurJ4ZKMLloi8GVXaQhchkSW8Z0bQxFI98HE4Xtx6iksbmF720fVeT81K3gq9/DrHEsAku66lxc4Jy/m/mgSluwoViw+crFe2Z85IoJMo9qRcetzE2mRYRajdLbmsAJph217XS4LG13v1UKPzWm7PbwsN4HVR/Z2Q4tEyW+3DeGb3wegbQ+vkimsadCAF6/pyI11w/FqsyLbKP9peVhVHLnD5qGgd3Rujm/l+mNOF7reMR5SBj1hQHgxWxpEAlPwuFsNu2DSaVJ14i4qFe021ZJ2FcwfayXHARj8UFrVmSfM+a/GMtBlZgqGx+W11NyEj7UfzzkT8deLsRC3ZKbQoqACX5wd9wc2FAAwvcMsSvqJodp2EC78RBuKrce0+YRv1HtBLebDQa3opYtoeZQcdEJtntDnpn/CvqebOiYn5U8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5bbcd0a8-bcab-44b4-149f-08d6ff201f9d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 19:04:35.1859 (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: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2553 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:04:42 -0000 QWxsLA0KDQpUaGlzIGVhcmx5IGRyYWZ0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZyaWVsLWFjbWUtaW50ZWdyYXRpb25zLyBjb3ZlcnMgaG93IEJSU0tJIGNvdWxkIHBv dGVudGlhbGx5IGJlIGludGVncmF0ZWQgd2l0aCBhbiBBQ01FIENBIGZvciBjZXJ0IGlzc3VhbmNl Lg0KDQpXaGF0IGlzIHRoZSBXRyBpbml0aWFsIGZlZWRiYWNrIG9uIHRoaXMgaWRlYT8gSSBoYXZl IHJlcXVlc3RlZCAxMG1pbnMgYXQgSUVURjEwNSB0byBwcmVzZW50L2Rpc2N1c3MuDQoNClJlbGF0 ZWQgd29yayBpcyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15dXNlZi1h Y21lLTNyZC1wYXJ0eS1kZXZpY2UtYXR0ZXN0YXRpb24vLCB3aGljaCBjb3ZlcnMgaG93IEFDTUUg Y291bGQgYmUgdXNlZCB0byBpc3N1ZSBkZXZpY2UgY2VydHMsIGJ1dCBkb2VzIG5vdCB1c2UgQlJT S0kuIFdlIGFyZSBjdXJyZW50bHkgZGlzY3Vzc2luZyBvZmZsaW5lIHdpdGggUmlmYWF0IGhvdyB3 ZSBjb3VsZCBwb3RlbnRpYWxseSBpbnRlZ3JhdGUgYm90aCBhcHByb2FjaGVzLiANCg0KT3dlbg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IA0KU2VudDogMDIgSnVseSAyMDE5IDE5OjUw DQpUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+OyBPd2VuIEZyaWVsIChvZnJpZWwpIDxv ZnJpZWxAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1mcmllbC1hY21lLWludGVncmF0aW9ucy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMtMDEudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE93ZW4gRnJpZWwgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMNClJldmlz aW9uOgkwMQ0KVGl0bGU6CQlBQ01FIEludGVncmF0aW9ucw0KRG9jdW1lbnQgZGF0ZToJMjAxOS0w Ny0wMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTcNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZnJpZWwt YWNtZS1pbnRlZ3JhdGlvbnMtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZyaWVsLWFjbWUtaW50 ZWdyYXRpb25zLTAxDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1mcmllbC1hY21lLWludGVncmF0aW9ucw0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mcmllbC1hY21lLWludGVn cmF0aW9ucy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgbXVsdGlw bGUgYWR2YW5jZWQgdXNlIGNhc2VzIGFuZCBpbnRlZ3JhdGlvbnMNCiAgIHRoYXQgQUNNRSBmYWNp bGl0YXRlcyB3aXRob3V0IGFueSBtb2RpZmljYXRpb25zIG9yIGVuaGFuY2VtZW50cw0KICAgcmVx dWlyZWQgdG8gdGhlIGJhc2UgQUNNRSBzcGVjaWZpY2F0aW9uLiAgVGhlc2UgdXNlIGNhc2VzIGFy ZSBub3QNCiAgIGltbWVkaWF0ZWx5IG9idmlvdXMgZnJvbSByZWFkaW5nIHRoZSBBQ01FIHNwZWNp ZmljYXRpb24gYW5kIHRodXMgYXJlDQogICBleHBsaWNpdGx5IGRvY3VtZW50ZWQgaGVyZS4gIFRo ZSB1c2UgY2FzZXMgaW5jbHVkZSBBQ01FIGlzc3VhbmNlIG9mDQogICBzdWJkb21haW4gY2VydGlm aWNhdGVzLCBhbmQgQUNNRSBpbnRlZ3JhdGlvbiB3aXRoIEVTVCBhbmQgVEVBUC4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Jul 2 14:12:48 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C19120708; Tue, 2 Jul 2019 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=WY6t+fFX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o7+c9oDr 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 jpox3FrMOJou; Tue, 2 Jul 2019 14:12:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B2912074D; Tue, 2 Jul 2019 14:12:38 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 596F421EAF; Tue, 2 Jul 2019 17:12:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 02 Jul 2019 17:12:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=u 8ERUr5XcY4u8gdhnnggpck5xdt0/VTLsUPphWEJP3w=; b=WY6t+fFXrl61SXVhd w0W0cWy5XSJwWaef60QRkyrsB0Ee+AoFEJ/AYD9ovmAvhDjp7bfyYBRfDCsSqCnO Vi1yXDsfk1rOORqHSSNDduE50Bpi1OdZ2/qG7rpcmJs5Ayo9VSZ02uxndmFDF0o8 WFvc4S92MvqG35yvLahiTpdJ5xBvD7Uy74mORA8tpuwcrrylzraYTl5jU3bGJXQt hTo83iEoV601h3gBv7KVIOuBGxbkr7nlSB+2UnRuwtBuzwfh1ZPPiU8RLmuTQpmm ZhTPHjP5lh9SumCWlMQbLHXZYjtaqmb4XghITnOww3QV0EUL/csXC1juCCTCReOK CADyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=u8ERUr5XcY4u8gdhnnggpck5xdt0/VTLsUPphWEJP 3w=; b=o7+c9oDrJIpO/hp9CKAxdA16tnTGfeoDMBMc+82/erenKEsAYJvTL0tNh K2VFFugVb0mIj9H2/i1XB/be0Mef1oa/ICIUzt9sWEfo6JEu7tYnqnbkkEXwJ++3 6+s3qYseRj6MEDZKImX1PAWWR3oB0YknQ+x3nC1oCbw3uCdhJfuW3VqBvSW/Dt2Q 8DwQJUbJ3GwSBbNxIkz4X6liIHFIf0d0pWrzTQL2ucDWas8xPsQhl+7/zeC6lXn7 DdGrv9ftoUxsAZg3JloDQnL4qg0CFXFiWG+XTv4+m/ENc4NZ3j7kq4zPF2WPiaoJ CbyTybzHIsoe9XrOLEo0Z3mrNnGwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedunecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.81]) by mail.messagingengine.com (Postfix) with ESMTPA id B175180059; Tue, 2 Jul 2019 17:12:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> Date: Tue, 2 Jul 2019 17:12:35 -0400 Cc: IESG , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 21:12:45 -0000 Hi all, I=E2=80=99ve been discussing this on my weekly call with the OPS ADs for = the last couple of weeks and based on the call that we had earlier today = my understanding is that now would be a good time to re-review. Regarding this text: "New work items will be adopted by the WG only if = their contributors target them to enter WG last call within a number of = IETF meeting cycles agreed by the AD.=E2=80=9D I still don=E2=80=99t get this. It is a very common case that = contributors think their drafts are going to get through to WGLC in X = cycles, and then they end up taking 2X or 10X because some new person = wanders into the WG or some other work starts up in another WG that has = an intersection with the work or someone changes jobs or any manner of = other things. The WG needs milestones with dates, preferably at the = point of approving the re-charter. Those might be missed too, but there = might as well not be two sets of markers laid down that are potentially = going to be missed rather than one set. Regarding the =E2=80=9Cindicative scope of possible work items=E2=80=9D = =E2=80=94 this doesn=E2=80=99t address my concern about the WG=E2=80=99s = scope. This charter is in contrast to the current ANIMA charter, which = says: "The initial set of work items is limited to the above list to = stay focused and avoid 'boiling the ocean=E2=80=99.=E2=80=9D I don=E2=80=99= t see the rationale for not carrying that forward to the next set of = specific work items where WG participants have demonstrated interest and = intent to carry the work forward. If that is the list of initial = milestone topics listed, then limiting to that makes sense to me. Thanks, Alissa > On Jun 10, 2019, at 9:02 PM, Brian E Carpenter = wrote: >=20 > Hi all, >=20 > I've taken the liberty of posting an update to the draft charter > at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried > to respond to all the IESG comments, and in particular: >=20 > (a) I deleted Intent from the summarised reference model framework, > since the reference model doesn't usefully define Intent. >=20 > (b) I tried to make the statement about workload throttling more > implementable. >=20 > (c) I still think that the laundry list of *possible* work items > is useful (it helps to define the scope) but I've tried make it > clear that it is only the "indicative scope of possible work items". > It really isn't mission creep; all the items mentioned relate > directly to the ANI and AF topics. >=20 > (d) I intentionally removed the reference to not covering machine > learning and AI. It isn't suggested anywhere in the reference model, > so why even mention it? >=20 > (e) I fixed nits and tuned the wording in several places. >=20 > I hope this helps. We really need a new charter before Montreal. > WG Chairs and AD, over to you... =20 >=20 > Regards > Brian Carpenter >=20 > On 02-May-19 08:39, Brian E Carpenter wrote: >> Hi Alissa, >>=20 >> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: >> ... >>> = ---------------------------------------------------------------------- >>> BLOCK: >>> = ---------------------------------------------------------------------- >>>=20 >>> (1) "Acceptance of work items by the WG will be scheduled/throttled = so that >>> contributors can target them to enter WG last call after not more = than a number >>> of IETF meeting cycles agreed by the AD." >>>=20 >>> I don't understand the implications of this. What happens if the = adopted work >>> items have not entered WGLC after the agreed number of cycles? If = the answer is >>> anything other than "the WG abandons the work," I don't understand = how this is >>> a throttling mechanism. A throttling mechanism would need an = explicit limit on >>> the number of adopted work items at any one time, I think. >>=20 >> I agree that the text is a bit illogical. In a sense it's = unnecessary, because >> every WG should be matching its workload to its capacity. Maybe = that's all >> we should say, rather than trying to describe a slightly vague = algorithm? >>=20 >>> (2) The proposed work items is a very large and somewhat unbounded = list of >>> items, whereas the purpose of writing a charter is to scope the work = of the WG >>> and hopefully set out a realistic work plan that will be accompanied = by >>> deployment. For a WG that has produced 5 documents in the last 5 = years, I think >>> the charter needs to more narrowly focus on the most highly = prioritized work >>> items. Once those are nearing completion, it seems as though = evaluation of what >>> is needed next based on deployment experience would then dictate the = next set >>> of items for another re-charter. >>=20 >> I think the point here is that now that the relatively small number = of >> infrastructure documents are almost finished, the next stage opens up >> the possibilities for a much wider range of work that builds on the >> infrastructure. The priorities aren't even obvious. So this goes with >> the previous point, and to quite some extent the criteria will be >> whether the WG has capacity more than which topic has priority. >>=20 >> That's why there's a bucket list of work items and a short list of >> immediate milestones. >>=20 >> Would this help? >>=20 >> s/Proposed work items include.../Possible work items include.../ >>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> It would be good to see milestones with dates before this gets = approved. >>>=20 >>> I think this charter would benefit from an English edit pass before = going out for external review. >>=20 >> I'll volunteer, when the open issues have been resolved. >>=20 >>> What is "compounding environment"? >>=20 >> An excellent question. >>=20 >> Brian >>=20 From nobody Tue Jul 2 19:33:58 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD051200DE; Tue, 2 Jul 2019 19:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 x_F61iD6Lmfx; Tue, 2 Jul 2019 19:33:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5939E120044; Tue, 2 Jul 2019 19:33:54 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0F5C24E8090805FFDA0C; Wed, 3 Jul 2019 03:33:52 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 3 Jul 2019 03:33:51 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Wed, 3 Jul 2019 10:31:46 +0800 From: Sheng Jiang To: "Owen Friel (ofriel)" , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wFAVG6QABAX6WA= Date: Wed, 3 Jul 2019 02:31:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999EA8D6@NKGEML515-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.9.126] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92999EA8D6NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 02:33:57 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92999EA8D6NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Owen, Thanks for your email. Your application are noted. I believe we have suffic= ient time for this coming meeting. Sheng From: Owen Friel (ofriel) [mailto:ofriel@cisco.com] Sent: Wednesday, July 3, 2019 2:58 AM To: Sheng Jiang ; anima@ietf.org Cc: anima-chairs@ietf.org Subject: RE: Call for agenda ANIMA @ IETF 105, Montreal Hi, I would like a time slot for: Name of time slot: BRSKI / Afternoon session I Name of draft(s): draft-friel-acme-integrations Time requested: 10 mins Presenter name(s): Owen Friel And the draft covers how to potentially integrate BRSKI with ACME. Owen From: Anima > On Beha= lf Of Sheng Jiang Sent: 26 June 2019 10:59 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs' email. Please note that ema= il to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B92999EA8D6NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Owe= n,

&n= bsp;

Thanks = for your email. Your application are noted. I believe we have sufficient ti= me for this coming meeting.

&n= bsp;

Sheng

&n= bsp;

 

From: Owen Friel (ofriel) [mailto:ofriel@cisco.com]
Sent: Wednesday, July 3, 2019 2:58 AM
To: Sheng Jiang <jiangsheng@huawei.com>; anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: RE: Call for agenda ANIMA @ IETF 105, Montreal

 

Hi,

I would like a time slot for:

 

Name of time slot: BRSKI / Afternoon session I<= /o:p>

Name of draft(s): draft-friel-acme-integrations=

Time requested: 10 mins

Presenter name(s): Owen Friel

 

And the draft covers how to potentially integrate BR= SKI with ACME.

 

Owen

 

 

 

Hi, all anima,
 =

We have been allo=
cated two sessions of 2 + 1.5 hour for the ANIMA WG meeting for IETF-10=
5 (Montreal) - Tuesday Morning session I and Afternoon session I. We are no=
w starting to collect agenda items for the sessions. Please send your reque=
st for agenda by July 11th, Thursday, to anima-chairs@ietf.org and both chairs’ email. Please note =
that email to a single chair may cause single failure.

 =



For this coming m=
eeting, we would like have the 1.5 hour session for BRSHI and Voucher relev=
ant topics and the 2 hour session for the others. As normal, the priority a=
mong these non-charter work items would be: these that have active discussi=
on in mail list, then these have submitted drafts, and topics without draft=
s.


 =



As you may observ=
ed, so far, our re-charter progress still not in the procedure. Until we ha=
ve the new charter in the place by the IETF 105 week, we still not be able =
to adopt any new work.


 =



Please send us (a=
nima-chairs at ietf.org<https://ietf.org/>;) requests=
 for time slot by July 11th, Thursday and include:


 =



Name of time slot=
:


Name of draft(s):=



Time requested:


Presenter name(s)=
:


 =



More details abou=
t the IETF 105, Montreal can be found at:


 =



https://www.ietf.org/how/meetings/105/


 =



Again, presenters=
 and draft authors please invoke active discussions in the ANIMA list. Mail=
 list is a very good place to discuss and reach consensus on technical issu=
es.


 =



Best regards,


 =



Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B92999EA8D6NKGEML515MBSchi_-- From nobody Tue Jul 2 20:29:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75212012A for ; Tue, 2 Jul 2019 20:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jgo6vJcoDM5x for ; Tue, 2 Jul 2019 20:28:59 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D7F120044 for ; Tue, 2 Jul 2019 20:28:58 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id w24so416399plp.2 for ; Tue, 02 Jul 2019 20:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=prDm03bH/ITF1dLJAeptl1ykWlMMVfEJIwR/PWjmR44=; b=ENxNR3TTalawg1uaZiRdaC2sSTJ64Ep83NXRLmwBEy469tZt6E8Lf1tZSRtiHpnwtP U//5qbocO0901X/pONGj9fz3rWpXhQ+ppgDF6OyCpjNXE/FYVI0Ej/D61OSrBlJKLBhU UkrWHKtsU+v1t0hOjg/6wnWKuPpZ4y2EuPbxKV6zOgQZNKBTj6XU+xyDOFq5jOcAlJbF PGOCGAMk9e5gvyYeljYgVkfNN2CUwd8p5SnYtil5O102RPU9mxBRM591cwR3AWJFy5To raZd92+Ma6XKyfrP292ZJ62EOJRFcdAp1CccZsUEWdc5c86spvFpJIPaYhTqi3Zzonqc cDiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=prDm03bH/ITF1dLJAeptl1ykWlMMVfEJIwR/PWjmR44=; b=axZbUQF8WOcaAteoBmgCoeBiQuI6qFO3xE0Q+uj8JJ7O6A++OAvEFluDnuCTdL0bo2 3azMO0BeBoPUVnejEsV4Us777KYKNynIsQ9PmsWJ2E6DLYNxXQdDIWYEr4JUaJSQVf/a DQTI23wCL6cg62Rc6QZfAvXoZfQ6UAltTJrKpF9dKSxLhdI6NWbMnmCu9mh3rvBEJ9sz 4GzwNmRRZZMBcDSG92GXhBxY7J6lObSgtmUjtRYot0NQ4M/OwWdyqo+pxE1YIvpzPr0I K/uzjA8649z2YitEmicZ/jEfE7cwHc1oNTN03ctr4KW7ksg4MNn1HbCsHWY/6WbL/tQp u+Iw== X-Gm-Message-State: APjAAAULeJRdS6KiHvtWuxFf17EYdA3Qu/wIyx9OYN6GubxF7sI1+j00 2FR4d3QF+gWSjz0BjoEX1rdWys1b X-Google-Smtp-Source: APXvYqw3/XQy/IzQ9XlRtTzBSGJhwwL190zoRO5MXet7fLcmvF/gwk6quUG3EjlW0IU+s1QhjUrCHg== X-Received: by 2002:a17:902:4643:: with SMTP id o61mr38919508pld.101.1562124538312; Tue, 02 Jul 2019 20:28:58 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id b26sm548739pfo.129.2019.07.02.20.28.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 20:28:57 -0700 (PDT) References: <156212371352.23945.6040124149039131688@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <156212371352.23945.6040124149039131688@ietfa.amsl.com> Message-ID: <62c1aef6-7f58-1b75-13bb-da07d075bb2f@gmail.com> Date: Wed, 3 Jul 2019 15:28:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156212371352.23945.6040124149039131688@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-grasp-bulk-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 03:29:01 -0000 A minor update of this draft. If the new charter is approved, we will request WG adoption. Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-grasp-bulk-04.txt Date: Tue, 02 Jul 2019 20:15:13 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP) Authors : Brian Carpenter Sheng Jiang Bing Liu Filename : draft-carpenter-anima-grasp-bulk-04.txt Pages : 12 Date : 2019-07-02 Abstract: This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP). Although not an equivalent of a file transfer protocol, such a technique may be used for non-urgent transfer of data too large to fit into a normal GRASP message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-grasp-bulk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk-04 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-grasp-bulk-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-grasp-bulk-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jul 3 07:40:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323812011F; Wed, 3 Jul 2019 07:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Gie-HISmDWkd; Wed, 3 Jul 2019 07:40:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031B912013E; Wed, 3 Jul 2019 07:40:27 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 894427B53DC2902F18EB; Wed, 3 Jul 2019 15:40:23 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 3 Jul 2019 15:40:23 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Wed, 3 Jul 2019 22:39:55 +0800 From: Sheng Jiang To: Alissa Cooper , Brian E Carpenter CC: IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) Thread-Index: AQHVMRrqZSr/q4kRhUGo8D1qiq9RK6a4jzsA Date: Wed, 3 Jul 2019 14:39:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999EAE8E@NKGEML515-MBS.china.huawei.com> References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.169.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 14:40:39 -0000 SGksIEFsaXNzYSwNCg0KVGhhbmtzIGZvciB5b3VyIGtpbmRseSByZXNwb25zZS4gSSBoYXZlIG1h ZGUgYSBuZXcgdmVyc2lvbiAoMi4wLjgpIGFjY29yZGluZyB0byB5b3VyIGZlZWRiYWNrLiBFeHBs YW5hdGlvbiBpbiBsaW5lcyBiZWxvdy4NCg0KUGxlYXNlIHNlZSBodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9hbmltYS93aWtpL1JlY2hhcnRlcjIwMTkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNvb3BlcncuaW5d DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzLCAyMDE5IDU6MTMgQU0NCj4gVG86IEJyaWFuIEUg Q2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQo+IENjOiBJRVNHIDxpZXNn QGlldGYub3JnPjsgYW5pbWEtY2hhaXJzQGlldGYub3JnOyBhbmltYUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW0FuaW1hXSBBbGlzc2EgQ29vcGVyJ3MgQmxvY2sgb24gY2hhcnRlci1pZXRmLWFu aW1hLTAxLTA1OiAod2l0aA0KPiBCTE9DSyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpIGFsbCwNCj4g DQo+IEnigJl2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBvbiBteSB3ZWVrbHkgY2FsbCB3aXRoIHRo ZSBPUFMgQURzIGZvciB0aGUgbGFzdA0KPiBjb3VwbGUgb2Ygd2Vla3MgYW5kIGJhc2VkIG9uIHRo ZSBjYWxsIHRoYXQgd2UgaGFkIGVhcmxpZXIgdG9kYXkgbXkNCj4gdW5kZXJzdGFuZGluZyBpcyB0 aGF0IG5vdyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byByZS1yZXZpZXcuDQo+IA0KPiBSZWdhcmRp bmcgdGhpcyB0ZXh0OiAiTmV3IHdvcmsgaXRlbXMgd2lsbCBiZSBhZG9wdGVkIGJ5IHRoZSBXRyBv bmx5IGlmIHRoZWlyDQo+IGNvbnRyaWJ1dG9ycyB0YXJnZXQgdGhlbSB0byBlbnRlciBXRyBsYXN0 IGNhbGwgd2l0aGluIGEgbnVtYmVyIG9mIElFVEYgbWVldGluZw0KPiBjeWNsZXMgYWdyZWVkIGJ5 IHRoZSBBRC7igJ0NCj4gDQo+IEkgc3RpbGwgZG9u4oCZdCBnZXQgdGhpcy4gSXQgaXMgYSB2ZXJ5 IGNvbW1vbiBjYXNlIHRoYXQgY29udHJpYnV0b3JzIHRoaW5rIHRoZWlyDQo+IGRyYWZ0cyBhcmUg Z29pbmcgdG8gZ2V0IHRocm91Z2ggdG8gV0dMQyBpbiBYIGN5Y2xlcywgYW5kIHRoZW4gdGhleSBl bmQgdXANCj4gdGFraW5nIDJYIG9yIDEwWCBiZWNhdXNlIHNvbWUgbmV3IHBlcnNvbiB3YW5kZXJz IGludG8gdGhlIFdHIG9yIHNvbWUNCj4gb3RoZXIgd29yayBzdGFydHMgdXAgaW4gYW5vdGhlciBX RyB0aGF0IGhhcyBhbiBpbnRlcnNlY3Rpb24gd2l0aCB0aGUgd29yayBvcg0KPiBzb21lb25lIGNo YW5nZXMgam9icyBvciBhbnkgbWFubmVyIG9mIG90aGVyIHRoaW5ncy4gVGhlIFdHIG5lZWRzDQo+ IG1pbGVzdG9uZXMgd2l0aCBkYXRlcywgcHJlZmVyYWJseSBhdCB0aGUgcG9pbnQgb2YgYXBwcm92 aW5nIHRoZSByZS1jaGFydGVyLg0KPiBUaG9zZSBtaWdodCBiZSBtaXNzZWQgdG9vLCBidXQgdGhl cmUgbWlnaHQgYXMgd2VsbCBub3QgYmUgdHdvIHNldHMgb2YgbWFya2Vycw0KPiBsYWlkIGRvd24g dGhhdCBhcmUgcG90ZW50aWFsbHkgZ29pbmcgdG8gYmUgbWlzc2VkIHJhdGhlciB0aGFuIG9uZSBz ZXQuDQoNCkkgaGF2ZSBqdXN0IGRlbGV0ZWQgdGhlIHNlbnRlbmNlLiBJdCdzIHNvbWV0aGluZyB0 aGUgY2hhaXJzIGNhbiBkbyBkdXJpbmcgdGhlIFdHIG1hbmFnZW1lbnQgcHJvY2Vzcy4gV2UgdHJp ZWQgdG8gZ2l2ZSBkcmFmdCBvd25lcnMgc29tZSBwcmVzc3VyZSBub3QgdG8gYmUgdG9vIHNsb3cg YnkgYWRkaW5nIHRoZXNlIHRleHQuIEkgZG8gYWdyZWUgdGhpcyBzaG91bGQgbm90IGJlIHNvIHJp Z2lkIGFzIHRoZXNlIHRleHQuIFNvLCBsZXQncyB0YWtlIGl0IG91dCBhbmQgdGhlIGNoYWlycyB3 aWxsIG1vbml0b3IgdGhlIHByb2dyZXNzIG9mIFdHIGRyYWZ0cyBjbG9zZWx5Lg0KDQo+IFJlZ2Fy ZGluZyB0aGUg4oCcaW5kaWNhdGl2ZSBzY29wZSBvZiBwb3NzaWJsZSB3b3JrIGl0ZW1z4oCdIOKA lCB0aGlzIGRvZXNu4oCZdA0KPiBhZGRyZXNzIG15IGNvbmNlcm4gYWJvdXQgdGhlIFdH4oCZcyBz Y29wZS4gVGhpcyBjaGFydGVyIGlzIGluIGNvbnRyYXN0IHRvIHRoZQ0KPiBjdXJyZW50IEFOSU1B IGNoYXJ0ZXIsIHdoaWNoIHNheXM6ICJUaGUgaW5pdGlhbCBzZXQgb2Ygd29yayBpdGVtcyBpcyBs aW1pdGVkIHRvDQo+IHRoZSBhYm92ZSBsaXN0IHRvIHN0YXkgZm9jdXNlZCBhbmQgYXZvaWQgJ2Jv aWxpbmcgdGhlIG9jZWFu4oCZLuKAnSBJIGRvbuKAmXQgc2VlIHRoZQ0KPiByYXRpb25hbGUgZm9y IG5vdCBjYXJyeWluZyB0aGF0IGZvcndhcmQgdG8gdGhlIG5leHQgc2V0IG9mIHNwZWNpZmljIHdv cmsgaXRlbXMNCj4gd2hlcmUgV0cgcGFydGljaXBhbnRzIGhhdmUgZGVtb25zdHJhdGVkIGludGVy ZXN0IGFuZCBpbnRlbnQgdG8gY2FycnkgdGhlDQo+IHdvcmsgZm9yd2FyZC4gSWYgdGhhdCBpcyB0 aGUgbGlzdCBvZiBpbml0aWFsIG1pbGVzdG9uZSB0b3BpY3MgbGlzdGVkLCB0aGVuIGxpbWl0aW5n IHRvDQo+IHRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuDQoNCkkgaGF2ZSBhZGRlZCBhIHNwZWNpZmlj IGxpc3Qgb2Ygd29yayBpdGVtcyBpbnRvIHRoZSBpbml0aWFsIG1pbGVzdG9uZSBsaXN0LiANCg0K T2J2aW91c2x5LCB0aGlzIGluaXRpYWwgbWlsZXN0b25lIGxpc3QgZG9lcyBOT1QgY292ZXIgYWxs IHRoZSB0b3BpY3MgdGhhdCBXRyBwYXJ0aWNpcGFudHMgaGF2ZSBzaG93ZWQgaW50ZXJlc3RzIGFu ZCB3aWxsaW5nbmVzcyB0byB3b3JrIG9uLiBUaGUgcHVycG9zZSB0byBoYXZlIHRoaXMgZGVzY3Jp cHRpb24gb2YgImluZGljYXRpdmUgc2NvcGUgb2YgcG9zc2libGUgd29yayBpdGVtc+KAnSBhcmUg YWN0dWFsbHkgdHdvOiBBLCBsaW1pdCB0aGUgcG90ZW50aWFsIHdvcmsgaXRlbXMgbm90IHRvIGJl IHRvbyB3aWRlLCBvdGhlcndpc2UsIHBlb3BsZSBtYXkgdGFrZSBhbnl0aGluZyBoYXMgdGhlIHdv cmsgImF1dG9tYXRpYyIgdG8gdGhlIFdHOyBCLCB0byBnaXZlIHRoZSBjaGFpcnMgYSBsaXR0bGUg Yml0IGZsZXhpYmlsaXR5IHRvIGFkb3B0IG5ldyB3b3JrcyBiZXlvbmQgdGhlIGluaXRpYWwgbWls ZXN0b25lIGxpc3QuIFdlIHRyeSB0byBhdm9pZCB0aGUgcHJvYmxlbSB0aGF0IGV2ZXJ5IHRpbWUg YSBuZXcgZHJhZnQgY29tZXMgdXAsIGl0IG1heSBiZWNvbWUgYSBjaGFydGVyIHJldmlzaW9uLCBw YXJ0aWN1bGFybHksIGdpdmluZyB0aGUgY3VycmVudCByZS1jaGFydGluZyBwcm9jZXNzIGhhdmUg dGFrZW4gdXMgbWFueSBtb250aHMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiBUaGFu a3MsDQo+IEFsaXNzYQ0KPiANCj4gPiBPbiBKdW4gMTAsIDIwMTksIGF0IDk6MDIgUE0sIEJyaWFu IEUgQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gSSd2ZSB0YWtlbiB0aGUgbGliZXJ0eSBvZiBwb3N0aW5n IGFuIHVwZGF0ZSB0byB0aGUgZHJhZnQgY2hhcnRlciBhdA0KPiA+IGh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL2FuaW1hL3dpa2kvUmVjaGFydGVyMjAxOS4gSSB0cmllZCB0bw0KPiA+IHJlc3Bv bmQgdG8gYWxsIHRoZSBJRVNHIGNvbW1lbnRzLCBhbmQgaW4gcGFydGljdWxhcjoNCj4gPg0KPiA+ IChhKSBJIGRlbGV0ZWQgSW50ZW50IGZyb20gdGhlIHN1bW1hcmlzZWQgcmVmZXJlbmNlIG1vZGVs IGZyYW1ld29yaywNCj4gPiBzaW5jZSB0aGUgcmVmZXJlbmNlIG1vZGVsIGRvZXNuJ3QgdXNlZnVs bHkgZGVmaW5lIEludGVudC4NCj4gPg0KPiA+IChiKSBJIHRyaWVkIHRvIG1ha2UgdGhlIHN0YXRl bWVudCBhYm91dCB3b3JrbG9hZCB0aHJvdHRsaW5nIG1vcmUNCj4gPiBpbXBsZW1lbnRhYmxlLg0K PiA+DQo+ID4gKGMpIEkgc3RpbGwgdGhpbmsgdGhhdCB0aGUgbGF1bmRyeSBsaXN0IG9mICpwb3Nz aWJsZSogd29yayBpdGVtcyBpcw0KPiA+IHVzZWZ1bCAoaXQgaGVscHMgdG8gZGVmaW5lIHRoZSBz Y29wZSkgYnV0IEkndmUgdHJpZWQgbWFrZSBpdCBjbGVhcg0KPiA+IHRoYXQgaXQgaXMgb25seSB0 aGUgImluZGljYXRpdmUgc2NvcGUgb2YgcG9zc2libGUgd29yayBpdGVtcyIuDQo+ID4gSXQgcmVh bGx5IGlzbid0IG1pc3Npb24gY3JlZXA7IGFsbCB0aGUgaXRlbXMgbWVudGlvbmVkIHJlbGF0ZSBk aXJlY3RseQ0KPiA+IHRvIHRoZSBBTkkgYW5kIEFGIHRvcGljcy4NCj4gPg0KPiA+IChkKSBJIGlu dGVudGlvbmFsbHkgcmVtb3ZlZCB0aGUgcmVmZXJlbmNlIHRvIG5vdCBjb3ZlcmluZyBtYWNoaW5l DQo+ID4gbGVhcm5pbmcgYW5kIEFJLiBJdCBpc24ndCBzdWdnZXN0ZWQgYW55d2hlcmUgaW4gdGhl IHJlZmVyZW5jZSBtb2RlbCwNCj4gPiBzbyB3aHkgZXZlbiBtZW50aW9uIGl0Pw0KPiA+DQo+ID4g KGUpIEkgZml4ZWQgbml0cyBhbmQgdHVuZWQgdGhlIHdvcmRpbmcgaW4gc2V2ZXJhbCBwbGFjZXMu DQo+ID4NCj4gPiBJIGhvcGUgdGhpcyBoZWxwcy4gV2UgcmVhbGx5IG5lZWQgYSBuZXcgY2hhcnRl ciBiZWZvcmUgTW9udHJlYWwuDQo+ID4gV0cgQ2hhaXJzIGFuZCBBRCwgb3ZlciB0byB5b3UuLi4N Cj4gPg0KPiA+IFJlZ2FyZHMNCj4gPiAgIEJyaWFuIENhcnBlbnRlcg0KPiA+DQo+ID4gT24gMDIt TWF5LTE5IDA4OjM5LCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPj4gSGkgQWxpc3NhLA0K PiA+Pg0KPiA+PiBPbiAwMi1NYXktMTkgMDg6MDUsIEFsaXNzYSBDb29wZXIgdmlhIERhdGF0cmFj a2VyIHdyb3RlOg0KPiA+PiAuLi4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiAtLQ0KPiA+Pj4g QkxPQ0s6DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gPj4+DQo+ID4+PiAoMSkgIkFj Y2VwdGFuY2Ugb2Ygd29yayBpdGVtcyBieSB0aGUgV0cgd2lsbCBiZSBzY2hlZHVsZWQvdGhyb3R0 bGVkDQo+ID4+PiBzbyB0aGF0IGNvbnRyaWJ1dG9ycyBjYW4gdGFyZ2V0IHRoZW0gdG8gZW50ZXIg V0cgbGFzdCBjYWxsIGFmdGVyIG5vdA0KPiA+Pj4gbW9yZSB0aGFuIGEgbnVtYmVyIG9mIElFVEYg bWVldGluZyBjeWNsZXMgYWdyZWVkIGJ5IHRoZSBBRC4iDQo+ID4+Pg0KPiA+Pj4gSSBkb24ndCB1 bmRlcnN0YW5kIHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhpcy4gV2hhdCBoYXBwZW5zIGlmIHRoZQ0K PiA+Pj4gYWRvcHRlZCB3b3JrIGl0ZW1zIGhhdmUgbm90IGVudGVyZWQgV0dMQyBhZnRlciB0aGUg YWdyZWVkIG51bWJlciBvZg0KPiA+Pj4gY3ljbGVzPyBJZiB0aGUgYW5zd2VyIGlzIGFueXRoaW5n IG90aGVyIHRoYW4gInRoZSBXRyBhYmFuZG9ucyB0aGUNCj4gPj4+IHdvcmssIiBJIGRvbid0IHVu ZGVyc3RhbmQgaG93IHRoaXMgaXMgYSB0aHJvdHRsaW5nIG1lY2hhbmlzbS4gQQ0KPiA+Pj4gdGhy b3R0bGluZyBtZWNoYW5pc20gd291bGQgbmVlZCBhbiBleHBsaWNpdCBsaW1pdCBvbiB0aGUgbnVt YmVyIG9mDQo+IGFkb3B0ZWQgd29yayBpdGVtcyBhdCBhbnkgb25lIHRpbWUsIEkgdGhpbmsuDQo+ ID4+DQo+ID4+IEkgYWdyZWUgdGhhdCB0aGUgdGV4dCBpcyBhIGJpdCBpbGxvZ2ljYWwuIEluIGEg c2Vuc2UgaXQncw0KPiA+PiB1bm5lY2Vzc2FyeSwgYmVjYXVzZSBldmVyeSBXRyBzaG91bGQgYmUg bWF0Y2hpbmcgaXRzIHdvcmtsb2FkIHRvIGl0cw0KPiA+PiBjYXBhY2l0eS4gTWF5YmUgdGhhdCdz IGFsbCB3ZSBzaG91bGQgc2F5LCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gZGVzY3JpYmUgYQ0KPiBz bGlnaHRseSB2YWd1ZSBhbGdvcml0aG0/DQo+ID4+DQo+ID4+PiAoMikgVGhlIHByb3Bvc2VkIHdv cmsgaXRlbXMgaXMgYSB2ZXJ5IGxhcmdlIGFuZCBzb21ld2hhdCB1bmJvdW5kZWQNCj4gPj4+IGxp c3Qgb2YgaXRlbXMsIHdoZXJlYXMgdGhlIHB1cnBvc2Ugb2Ygd3JpdGluZyBhIGNoYXJ0ZXIgaXMg dG8gc2NvcGUNCj4gPj4+IHRoZSB3b3JrIG9mIHRoZSBXRyBhbmQgaG9wZWZ1bGx5IHNldCBvdXQg YSByZWFsaXN0aWMgd29yayBwbGFuIHRoYXQNCj4gPj4+IHdpbGwgYmUgYWNjb21wYW5pZWQgYnkg ZGVwbG95bWVudC4gRm9yIGEgV0cgdGhhdCBoYXMgcHJvZHVjZWQgNQ0KPiA+Pj4gZG9jdW1lbnRz IGluIHRoZSBsYXN0IDUgeWVhcnMsIEkgdGhpbmsgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gbW9yZQ0K PiA+Pj4gbmFycm93bHkgZm9jdXMgb24gdGhlIG1vc3QgaGlnaGx5IHByaW9yaXRpemVkIHdvcmsg aXRlbXMuIE9uY2UgdGhvc2UNCj4gPj4+IGFyZSBuZWFyaW5nIGNvbXBsZXRpb24sIGl0IHNlZW1z IGFzIHRob3VnaCBldmFsdWF0aW9uIG9mIHdoYXQgaXMNCj4gPj4+IG5lZWRlZCBuZXh0IGJhc2Vk IG9uIGRlcGxveW1lbnQgZXhwZXJpZW5jZSB3b3VsZCB0aGVuIGRpY3RhdGUgdGhlIG5leHQNCj4g c2V0IG9mIGl0ZW1zIGZvciBhbm90aGVyIHJlLWNoYXJ0ZXIuDQo+ID4+DQo+ID4+IEkgdGhpbmsg dGhlIHBvaW50IGhlcmUgaXMgdGhhdCBub3cgdGhhdCB0aGUgcmVsYXRpdmVseSBzbWFsbCBudW1i ZXINCj4gPj4gb2YgaW5mcmFzdHJ1Y3R1cmUgZG9jdW1lbnRzIGFyZSBhbG1vc3QgZmluaXNoZWQs IHRoZSBuZXh0IHN0YWdlIG9wZW5zDQo+ID4+IHVwIHRoZSBwb3NzaWJpbGl0aWVzIGZvciBhIG11 Y2ggd2lkZXIgcmFuZ2Ugb2Ygd29yayB0aGF0IGJ1aWxkcyBvbg0KPiA+PiB0aGUgaW5mcmFzdHJ1 Y3R1cmUuIFRoZSBwcmlvcml0aWVzIGFyZW4ndCBldmVuIG9idmlvdXMuIFNvIHRoaXMgZ29lcw0K PiA+PiB3aXRoIHRoZSBwcmV2aW91cyBwb2ludCwgYW5kIHRvIHF1aXRlIHNvbWUgZXh0ZW50IHRo ZSBjcml0ZXJpYSB3aWxsDQo+ID4+IGJlIHdoZXRoZXIgdGhlIFdHIGhhcyBjYXBhY2l0eSBtb3Jl IHRoYW4gd2hpY2ggdG9waWMgaGFzIHByaW9yaXR5Lg0KPiA+Pg0KPiA+PiBUaGF0J3Mgd2h5IHRo ZXJlJ3MgYSBidWNrZXQgbGlzdCBvZiB3b3JrIGl0ZW1zIGFuZCBhIHNob3J0IGxpc3Qgb2YNCj4g Pj4gaW1tZWRpYXRlIG1pbGVzdG9uZXMuDQo+ID4+DQo+ID4+IFdvdWxkIHRoaXMgaGVscD8NCj4g Pj4NCj4gPj4gcy9Qcm9wb3NlZCB3b3JrIGl0ZW1zIGluY2x1ZGUuLi4vUG9zc2libGUgd29yayBp dGVtcyBpbmNsdWRlLi4uLw0KPiA+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+Pj4gLS0NCj4gPj4+IENPTU1FTlQ6DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4g Pj4+DQo+ID4+PiBJdCB3b3VsZCBiZSBnb29kIHRvIHNlZSBtaWxlc3RvbmVzIHdpdGggZGF0ZXMg YmVmb3JlIHRoaXMgZ2V0cyBhcHByb3ZlZC4NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIHRoaXMgY2hh cnRlciB3b3VsZCBiZW5lZml0IGZyb20gYW4gRW5nbGlzaCBlZGl0IHBhc3MgYmVmb3JlIGdvaW5n DQo+IG91dCBmb3IgZXh0ZXJuYWwgcmV2aWV3Lg0KPiA+Pg0KPiA+PiBJJ2xsIHZvbHVudGVlciwg d2hlbiB0aGUgb3BlbiBpc3N1ZXMgaGF2ZSBiZWVuIHJlc29sdmVkLg0KPiA+Pg0KPiA+Pj4gV2hh dCBpcyAiY29tcG91bmRpbmcgZW52aXJvbm1lbnQiPw0KPiA+Pg0KPiA+PiBBbiBleGNlbGxlbnQg cXVlc3Rpb24uDQo+ID4+DQo+ID4+ICAgIEJyaWFuDQo+ID4+DQoNCg== From nobody Wed Jul 3 11:35:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC767120332 for ; Wed, 3 Jul 2019 11:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BteJQTSskMYk for ; Wed, 3 Jul 2019 11:35:35 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id C02471200B6 for ; Wed, 3 Jul 2019 11:35:34 -0700 (PDT) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217] port 22746) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id x63IZW9C010934 for ; Wed, 3 Jul 2019 14:35:32 -0400 To: anima@ietf.org From: William Atwood Openpgp: preference=signencrypt Autocrypt: addr=william.atwood@concordia.ca; prefer-encrypt=mutual; keydata= mQGiBEmjdrMRBADawl3I6QQW9RTYKHQk0tMhjbbgi7clCKZzmgTOOHKYDil9J68+xyTdXlBT ud5crBx2kYf334Uf5fOBNBh6Z/3kUr2qkvVHXAp+yox81wao8pBwQ5wcnhPmnGhpsapCMeBA 3deiCQfvd9AVygrNZOJvW526PIHiNvob2pDT4ef0iwCgroVoHugkt+84Ly3jL9lcFFmqW38D /2exybJrzefDFGHExaQinYRwIovHhdilirh3k6BcRaS6xWUbWsra+w0OSQWCt+Ooaj6Zmeio 13U5lybjD4M0Se7TI0AW6JJsHot3x69/2Uq2OWb1cddezafZ4+vlNybC5LZ+tynTVt2RB7lE Yy34W9kTWIHsaFOLUjDaZW+ScpKoA/9yXM3FY7hUTBEgP5+CUyX4zYsnxtmeurhVi4D3Ri1e TRQhE/WxaVsxxqJuFNx/rzOPwnekWa06cb4mKYHJ6HJ/q1hjSCOvhlSUgLwQ6XiqYW/dulfL ulq6d9w01gApWPNdaimLOnZi/Of52YO7RZroSNPBwC71hOxzQCzeHZLgaLQxSm9obiBXaWxs aWFtIEF0d29vZCA8d2lsbGlhbS5hdHdvb2RAY29uY29yZGlhLmNhPohjBBMRAgAjAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAlC5EYcCGQEACgkQV5o4IdDwBVhFdACePdBrMqD3jC9V 53DbmgWkIR5oHVAAn1HPsfaMXQsIyim9d2wpwQunGDcXuQINBEmjdrMQCACDziZLszCCtC0i 195vC7UlKnKEE7rLKP+tzpJuPb6EW27xBtJ2cr6RXZQ84rrHvgczmhaht7kUPyyAFVUG2pbK 9vOBPcurdimtz4cc5FJ6v2wi9NoNaxag8MY2WYYzH7Fs4Bh7ZK7B6pR/lYVNltu8vxT7MO4p k+jjDaKkYU4VlN9dWrwTapmBbYafdOHhxnvxYrr3TsLdpYbGiucDwLtWGgd7+jx9LUT9tStg RgSYpwULZbQWHjSGRAXHtOzsk01TcTUP+rzbqteQ+3n867848rnJxoOWdOF73TR32dif0osf DAr4EuHHSkRI8a7me8zcVVZGhjQsp6JGsnhKO0AfAAMFB/9Cym72Z7nNw4ewqhVAVPal+tQG zkyh1S8vTEo6GdOK7eapc1OaSK7YCAS6UmFVTgoAjRBUPA5L7aLorSUXwzjZ7X26Pn2ywlnI c8+7AlbeGnggEg1h95QQTly+xU3ZEiBF0LhhyAwpISqGiz7zq44w2pqAxnAiKNX2xZxjHdZ+ yDMxT86Yj/U7K6ITv4/GwygS7bMt9+wXYRzvr9gHr5jKMEsTeIJHi5UNWLYfpfmhyF6sZ3KT qHFVAZ6yu2xDuAEhnIWaOUC2+Z9XHLMvgSrxIleqkKJiWZbAc9C1F/iV+DeQ7rNPNg9pN2Kr imkVfjdMTCwORUeeGprBurp3wCy/iEkEGBECAAkFAkmjdrMCGwwACgkQV5o4IdDwBVgd9gCf YD8t+Q9rphTC4HpOX9lHYEIIko8An2V2hchJax+LOGzSQOXOj8OgK3g3 Organization: Concordia University, Montreal Message-ID: <7019ff25-e185-87c3-6a0a-bc53528856dd@concordia.ca> Date: Wed, 3 Jul 2019 14:35:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2019-07-03 14:35:33 EDT Archived-At: Subject: [Anima] Draft Charter 2.0.8 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 18:35:38 -0000 In view of the fact that the Reference Model is specified as "draft-ietf-anima-reference-model already approved for publication", and that the ACP and Vouchers are specified by their RFC numbers, and that BRSKI and GRASP are just as important as building blocks, I suggest that citations should be given for BRSKI and GRASP. Bill -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Wed Jul 3 15:28:35 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB591206A0 for ; Wed, 3 Jul 2019 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 be5xFQA7M4dp for ; Wed, 3 Jul 2019 15:28:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1971204C2 for ; Wed, 3 Jul 2019 15:28:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 83DE738192; Wed, 3 Jul 2019 18:26:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA601BB7; Wed, 3 Jul 2019 18:28:22 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" , "Owen Friel \(ofriel\)" cc: Rifaat Shekh-Yusef In-Reply-To: References: <156209339375.23780.16389385862360970000.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 22:28:34 -0000 --=-=-= Content-Type: text/plain Owen Friel (ofriel) wrote: > This early draft > https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers > how BRSKI could potentially be integrated with an ACME CA for cert > issuance. I read it. While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I'm not actually sure what it means from a standards point of view. My code base does not connect the RA to LetsEncrypt, but rather uses LetsEncrypt to produce IDevIDs from a provisioning process. I think that you have a problem in STEP 2 (section 3), and STEP 3 (section 4), STEP 3 (section 5). In each place where you post a CSR, you omit the part where you get the CSRattributes. At some point the pledge needs to learn about what the delegated domain is ("domain.com"). In section 4, the figures (which need to be numbered, btw), is labelled a Pledge, but since there is no BRSKI, it should "Client" > Related work is > https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/, > which covers how ACME could be used to issue device certs, but does not > use BRSKI. We are currently discussing offline with Rifaat how we could > potentially integrate both approaches. I'll read this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0dLAYACgkQgItw+93Q 3WWOLAgAgMUxJRVmni6bVz1C9M7YQp0GfYUk6lkIs/FvLvEaJg8XSo/KLs6HSjrB K6usZg9hHrkEjVHigTdA3RqJ51gOtzpWiIHPainkgzf3DURjfQprqgHFO/eBpZ8l Yt67y/0WPbBKDx6ENmVh3cMh4SgG4EE6rx56tObgt3hQ8BiJXjg13etKKI4TaYMR doZOUl5L0XLzDAscfCe0t7kaaTgqxV6Ny9iXmImai5qTFPnWBbVOoVEGedNh4l73 F31WDNwbfVL05DSsSfmky/dg3BEzRlFRxDpIWUXYUshOBOP8AlQCVplO1dSRDFbc 1vo+2hJjWaZgeCjyjXb5avy4feqvIA== =8TrB -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 4 13:54:30 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7AE120254; Thu, 4 Jul 2019 13:54:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156227366025.12024.1252051574992362497@ietfa.amsl.com> Date: Thu, 04 Jul 2019 13:54:20 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 20:54:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Voucher Artifacts for Bootstrapping Protocols Authors : Michael Richardson Peter van der Stok Panos Kampanakis Filename : draft-ietf-anima-constrained-voucher-04.txt Pages : 43 Date : 2019-07-04 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-est] protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 4 14:18:36 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5134120165 for ; Thu, 4 Jul 2019 14:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rqkRDsT1q0b8 for ; Thu, 4 Jul 2019 14:18:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4CC1200C1 for ; Thu, 4 Jul 2019 14:18:30 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 00BA238194 for ; Thu, 4 Jul 2019 17:16:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3FBB6BA4 for ; Thu, 4 Jul 2019 17:18:29 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <156227366073.12024.15876738877597643030.idtracker@ietfa.amsl.com> References: <156227366073.12024.15876738877597643030.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] appendix C changes for draft-ietf-anima-constrained-voucher-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 21:18:34 -0000 --=-=-= Content-Type: text/plain > URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-constrained-voucher-04.txt Appendix C is updated. Jim found that I had done the COSE SIGN1 body wrong. Specifically, my code did not CBOR encode the content before signing. (Naturally, my code interoperated with itself) I have corrected this and updated the examples. Now that the contents are CBOR encoding, one can not in the DIAG format easily the voucher(request) object embedded. I have thus far included the CBOR DIAG output as well as the base64 encoding of the CBOR. I think that there is little value in including the DIAG format output as there is little one can see directly. I could artifically decode the inner content as an examplar; I'd have to think about if I can automate this easily, otherwise things will get out of sync. The -04 version has some unfortunate formatting oops, which I'll fix before monday and repost. I don't expect to make any other substantive changes other than a few grammar typos I noticed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0ebSQACgkQgItw+93Q 3WXzVAgAneTGrfQx83omGMxafFXwOuhBQ4iZVylIEj4g28kEaVzBvXbYeUEj/yfr /ve99eR1gk4Iy7jIkxOQjBjyvWpYTLOSFnraRP6K5qRVK8Mrx44bHSKQtIX6oOxU R/Sdakm1KVVfFtcmpyJg/VhNDQToDF4IWxLd1CVDxh32F3bNwHZt7TyWAtrkP1Iu 2XwJjNREG1r81UVbveEX026pLxPylSs7sISLnrMoLe/N2UaUUuscapB2MK+rFQ92 BgX9kP3TlXfCiPDlWYqSxByGB8d7uobfHpZpGMweQCY2697T0HJxojXJah/cMdRP uppS8jPS6Nk8CfyCv8FqdgPIzl7LLQ== =2IrJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 4 21:09:34 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F811200E9; Thu, 4 Jul 2019 21:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CGNzeMzJgUVI; Thu, 4 Jul 2019 21:09:31 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD551200D7; Thu, 4 Jul 2019 21:09:31 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id q10so3701107pff.9; Thu, 04 Jul 2019 21:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vx3JsG2OooZWaI/5JaICJ7B5Fs1zPQaLiOVGpA2pr1s=; b=Jp6XW+OtJA6CqDIdOqNHA0QtRwNU77DW2w6BKLgQvdrfXBnlYOdF3/H/Q5GlRt0clV xj7Vo3Q0rvyLuPhqyXQjyhXMM6UGR1+xDZZwXHQAs6fxv92nCsIuuGvmXjyJvyR9b1Yb NOspqqm8WWVkvjygT2PKpP4JB9FlqysQGdIBmpJLXJB9FxMgKPyhTW0pwirypna2CuB1 VoBqSGClivR9ssl+MG2VBADQsdcH6yC8//AGQnvJvLF/mwdUayqhpyb39oJkD5DAV1wA V29JBICHiIZAHOHJOmihkt7CGvH6co6MY9xTbHE1WFeEyjbgo3PQCVTAW3ZKe9lkLKe+ 3BcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vx3JsG2OooZWaI/5JaICJ7B5Fs1zPQaLiOVGpA2pr1s=; b=DA+AGFHn0w4Qrnfwr1TaeVDcD7NrAm+V3V8sOme3ToJqt7Ud8OXphOqhcGL/ov50TY bsH8U3hX8yEgzFvR15bHt7HCiH6Dq9ihOR7+ZAhNCcLkCQEW2bwo+bOMY1flJYZTcris 55zoosW1s9fNjT2RJKt959IGP3W0tVjC+HgzKMNCoLITiIorBqjkglNWcU/Lp8SWFE4F pBamKtSvRq8LM0Y1ml34dKl+PpQ6ZgdVBdXEBOb2a1qx/yaqcyyf07nVxGAjOt2ox26h 41rvg94z9Wj1wLJTtuOw6EpGHsap6/db9onSPOVn5xrumINnRA3NZHja4Uork7Ku/FDC VO0g== X-Gm-Message-State: APjAAAUzwCGP6dKjgv0SXPU32oDcTa4EH76JyPOVNRwWewO6IZzxF7d9 iTiTLKdJV6lqY9NGGVih6TMvjrpv X-Google-Smtp-Source: APXvYqw2oLc9yfPEZirJWa748HC8dyl+Ks5PSoSkvxgd+9MAbry67GKrxcrkzZYRx9PboLZGEGTMDA== X-Received: by 2002:a63:e251:: with SMTP id y17mr2298046pgj.8.1562299770333; Thu, 04 Jul 2019 21:09:30 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id a21sm14264567pgd.45.2019.07.04.21.09.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 21:09:29 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" , anima-ads@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> <346b299e-9588-2c0b-5455-6140ccbf36c1@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <142b13de-e87b-656c-f75b-f703972c7036@gmail.com> Date: Fri, 5 Jul 2019 16:09:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <346b299e-9588-2c0b-5455-6140ccbf36c1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 04:09:33 -0000 Hi, Let me be a bit more precise. This is a request for 3 WG slots at IETF105= : 1. draft-ietf-anima-grasp-api (GRASP API) Speaker: Brian Carpenter (on site) Purpose: Reminder of draft and request for WG Last Call Time: 5 minutes 2. draft-carpenter-anima-l2acp-scenarios (Layer 2 ACP) Speaker: Brian Carpenter (on site) Purpose: Introducing a new proposal (deferred from IETF104) Time: 15 minutes 3. draft-carpenter-anima-asa-guidelines and draft-carpenter-anima-grasp-b= ulk (Drafts related to autonomic ecosystem) Speaker: Brian Carpenter (on site) Purpose: Reminder of drafts and requests for WG adoption (under new chart= er) Time: 10 minutes Regards Brian Carpenter On 29-Jun-19 11:21, Brian E Carpenter wrote: > Hi Sheng and Toerless, and ADs, >=20 > This is quite difficult without knowing if the new charter has been app= roved. Is this on the IESG agenda? If not, why not?? We've been waiting m= onths. >=20 > If we do have the new charter I would like to propose several topics fo= r WG adoption: >=20 > draft-carpenter-anima-asa-guidelines - previously presented, only discu= ssion needed > draft-carpenter-anima-grasp-bulk - previously presented, only discussi= on needed >=20 > draft-carpenter-anima-l2acp-scenarios - not previously presented, 10 mi= nutes requested in any case. Possibly this also fits under the old charte= r. >=20 > In any case I would like to propose that draft-ietf-anima-grasp-api sho= uld move to WG Last Call under the old charter. Again, that has been prev= iously presented, only discussion is needed. >=20 > Regards > Brian Carpenter >=20 > On 26-Jun-19 21:59, Sheng Jiang wrote: >> Hi, all anima, >> >> =C2=A0 >> >> We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG m= eeting for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon = session I. We are now starting to collect agenda items for the sessions. = Please send your request for agenda by July 11th, Thursday, to anima-chai= rs@ietf.org and both chairs=E2=80=99 email= =2E Please note that email to a single chair may cause single failure. >> >> =C2=A0 >> >> For this coming meeting, we would like have the 1.5 hour session for B= RSHI and Voucher relevant topics and the 2 hour session for the others. A= s normal, the priority among these non-charter work items would be: these= that have active discussion in mail list, then these have submitted draf= ts, and topics without drafts. >> >> =C2=A0 >> >> As you may observed, so far, our re-charter progress still not in the = procedure. Until we have the new charter in the place by the IETF 105 wee= k, we still not be able to adopt any new work. >> >> =C2=A0 >> >> Please send us (anima-chairs at ietf.org ;) requests for time slot by July 11th, Thur= sday and include: >> >> =C2=A0 >> >> Name of time slot: >> >> Name of draft(s): >> >> Time requested: >> >> Presenter name(s): >> >> =C2=A0 >> >> More details about the IETF 105, Montreal can be found at: >> >> =C2=A0 >> >> https://www.ietf.org/how/meetings/105/ >> >> =C2=A0 >> >> Again, presenters and draft authors please invoke active discussions i= n the ANIMA list. Mail list is a very good place to discuss and reach con= sensus on technical issues. >> >> =C2=A0 >> >> Best regards, >> >> =C2=A0 >> >> Sheng >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Fri Jul 5 02:39:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F23D120153; Fri, 5 Jul 2019 02:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yk2a-m4QgonU; Fri, 5 Jul 2019 02:39:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8846E1200CE; Fri, 5 Jul 2019 02:39:16 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 78DAD9287D8C41A5BACE; Fri, 5 Jul 2019 10:39:14 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 5 Jul 2019 10:39:14 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Fri, 5 Jul 2019 17:39:08 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" CC: "anima-chairs@ietf.org" , "anima-ads@ietf.org" Thread-Topic: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wBv12+AATfSRAAAHD77UA== Date: Fri, 5 Jul 2019 09:39:07 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999EC412@NKGEML515-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> <346b299e-9588-2c0b-5455-6140ccbf36c1@gmail.com> <142b13de-e87b-656c-f75b-f703972c7036@gmail.com> In-Reply-To: <142b13de-e87b-656c-f75b-f703972c7036@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 09:39:20 -0000 SGksIEJyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgZW1haWwuIFlvdXIgYXBwbGljYXRpb24gYXJl IG5vdGVkLiBTbyBmYXIsIHdlIGhhdmUgNyBhcHBsaWNhdGlvbnMgZm9yIDcwbWlucywgaW5jbHVk aW5nIHlvdXIgdGhyZWUuIEkgYmVsaWV2ZSB3ZSBoYXZlIHN1ZmZpY2llbnQgdGltZSBmb3IgdGhp cyBjb21pbmcgbWVldGluZy4NCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDA1LCAyMDE5IDEyOjA5IFBNDQo+IFRvOiBT aGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPjsgYW5pbWFAaWV0Zi5vcmcNCj4gQ2M6 IGFuaW1hLWNoYWlyc0BpZXRmLm9yZzsgYW5pbWEtYWRzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQW5pbWFdIENhbGwgZm9yIGFnZW5kYSBBTklNQSBAIElFVEYgMTA1LCBNb250cmVhbA0KPiAN Cj4gSGksDQo+IA0KPiBMZXQgbWUgYmUgYSBiaXQgbW9yZSBwcmVjaXNlLiBUaGlzIGlzIGEgcmVx dWVzdCBmb3IgMyBXRyBzbG90cyBhdCBJRVRGMTA1Og0KPiANCj4gMS4gZHJhZnQtaWV0Zi1hbmlt YS1ncmFzcC1hcGkgKEdSQVNQIEFQSSkNCj4gU3BlYWtlcjogQnJpYW4gQ2FycGVudGVyIChvbiBz aXRlKQ0KPiBQdXJwb3NlOiBSZW1pbmRlciBvZiBkcmFmdCBhbmQgcmVxdWVzdCBmb3IgV0cgTGFz dCBDYWxsDQo+IFRpbWU6IDUgbWludXRlcw0KPiANCj4gMi4gZHJhZnQtY2FycGVudGVyLWFuaW1h LWwyYWNwLXNjZW5hcmlvcyAoTGF5ZXIgMiBBQ1ApDQo+IFNwZWFrZXI6IEJyaWFuIENhcnBlbnRl ciAob24gc2l0ZSkNCj4gUHVycG9zZTogSW50cm9kdWNpbmcgYSBuZXcgcHJvcG9zYWwgKGRlZmVy cmVkIGZyb20gSUVURjEwNCkNCj4gVGltZTogMTUgbWludXRlcw0KPiANCj4gMy4gZHJhZnQtY2Fy cGVudGVyLWFuaW1hLWFzYS1ndWlkZWxpbmVzIGFuZCBkcmFmdC1jYXJwZW50ZXItYW5pbWEtZ3Jh c3AtYnVsaw0KPiAoRHJhZnRzIHJlbGF0ZWQgdG8gYXV0b25vbWljIGVjb3N5c3RlbSkNCj4gU3Bl YWtlcjogQnJpYW4gQ2FycGVudGVyIChvbiBzaXRlKQ0KPiBQdXJwb3NlOiBSZW1pbmRlciBvZiBk cmFmdHMgYW5kIHJlcXVlc3RzIGZvciBXRyBhZG9wdGlvbiAodW5kZXIgbmV3IGNoYXJ0ZXIpDQo+ IFRpbWU6IDEwIG1pbnV0ZXMNCj4gDQo+IFJlZ2FyZHMNCj4gICAgQnJpYW4gQ2FycGVudGVyDQo+ IA0KPiBPbiAyOS1KdW4tMTkgMTE6MjEsIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KPiA+IEhp IFNoZW5nIGFuZCBUb2VybGVzcywgYW5kIEFEcywNCj4gPg0KPiA+IFRoaXMgaXMgcXVpdGUgZGlm ZmljdWx0IHdpdGhvdXQga25vd2luZyBpZiB0aGUgbmV3IGNoYXJ0ZXIgaGFzIGJlZW4gYXBwcm92 ZWQuIElzDQo+IHRoaXMgb24gdGhlIElFU0cgYWdlbmRhPyBJZiBub3QsIHdoeSBub3Q/PyBXZSd2 ZSBiZWVuIHdhaXRpbmcgbW9udGhzLg0KPiA+DQo+ID4gSWYgd2UgZG8gaGF2ZSB0aGUgbmV3IGNo YXJ0ZXIgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2Ugc2V2ZXJhbCB0b3BpY3MgZm9yIFdHDQo+IGFk b3B0aW9uOg0KPiA+DQo+ID4gZHJhZnQtY2FycGVudGVyLWFuaW1hLWFzYS1ndWlkZWxpbmVzIC0g cHJldmlvdXNseSBwcmVzZW50ZWQsIG9ubHkNCj4gPiBkaXNjdXNzaW9uIG5lZWRlZCBkcmFmdC1j YXJwZW50ZXItYW5pbWEtZ3Jhc3AtYnVsayAgLSBwcmV2aW91c2x5DQo+ID4gcHJlc2VudGVkLCBv bmx5IGRpc2N1c3Npb24gbmVlZGVkDQo+ID4NCj4gPiBkcmFmdC1jYXJwZW50ZXItYW5pbWEtbDJh Y3Atc2NlbmFyaW9zIC0gbm90IHByZXZpb3VzbHkgcHJlc2VudGVkLCAxMCBtaW51dGVzDQo+IHJl cXVlc3RlZCBpbiBhbnkgY2FzZS4gUG9zc2libHkgdGhpcyBhbHNvIGZpdHMgdW5kZXIgdGhlIG9s ZCBjaGFydGVyLg0KPiA+DQo+ID4gSW4gYW55IGNhc2UgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2Ug dGhhdCBkcmFmdC1pZXRmLWFuaW1hLWdyYXNwLWFwaSBzaG91bGQgbW92ZQ0KPiB0byBXRyBMYXN0 IENhbGwgdW5kZXIgdGhlIG9sZCBjaGFydGVyLiBBZ2FpbiwgdGhhdCBoYXMgYmVlbiBwcmV2aW91 c2x5IHByZXNlbnRlZCwNCj4gb25seSBkaXNjdXNzaW9uIGlzIG5lZWRlZC4NCj4gPg0KPiA+IFJl Z2FyZHMNCj4gPiAgICBCcmlhbiBDYXJwZW50ZXINCj4gPg0KPiA+IE9uIDI2LUp1bi0xOSAyMTo1 OSwgU2hlbmcgSmlhbmcgd3JvdGU6DQo+ID4+IEhpLCBhbGwgYW5pbWEsDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+IFdlIGhhdmUgYmVlbiBhbGxvY2F0ZWQgdHdvIHNlc3Npb25zIG9mIDIgKyAxLjUg aG91ciBmb3IgdGhlIEFOSU1BIFdHDQo+IG1lZXRpbmcgZm9yIElFVEYtMTA1IChNb250cmVhbCkg LSBUdWVzZGF5IE1vcm5pbmcgc2Vzc2lvbiBJIGFuZCBBZnRlcm5vb24NCj4gc2Vzc2lvbiBJLiBX ZSBhcmUgbm93IHN0YXJ0aW5nIHRvIGNvbGxlY3QgYWdlbmRhIGl0ZW1zIGZvciB0aGUgc2Vzc2lv bnMuIFBsZWFzZQ0KPiBzZW5kIHlvdXIgcmVxdWVzdCBmb3IgYWdlbmRhIGJ5IEp1bHkgMTF0aCwg VGh1cnNkYXksIHRvIGFuaW1hLWNoYWlyc0BpZXRmLm9yZw0KPiA8bWFpbHRvOmFuaW1hLWNoYWly c0BpZXRmLm9yZz4gYW5kIGJvdGggY2hhaXJz4oCZIGVtYWlsLiBQbGVhc2Ugbm90ZSB0aGF0IGVt YWlsIHRvDQo+IGEgc2luZ2xlIGNoYWlyIG1heSBjYXVzZSBzaW5nbGUgZmFpbHVyZS4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gRm9yIHRoaXMgY29taW5nIG1lZXRpbmcsIHdlIHdvdWxkIGxpa2Ug aGF2ZSB0aGUgMS41IGhvdXIgc2Vzc2lvbiBmb3IgQlJTSEkNCj4gYW5kIFZvdWNoZXIgcmVsZXZh bnQgdG9waWNzIGFuZCB0aGUgMiBob3VyIHNlc3Npb24gZm9yIHRoZSBvdGhlcnMuIEFzIG5vcm1h bCwgdGhlDQo+IHByaW9yaXR5IGFtb25nIHRoZXNlIG5vbi1jaGFydGVyIHdvcmsgaXRlbXMgd291 bGQgYmU6IHRoZXNlIHRoYXQgaGF2ZSBhY3RpdmUNCj4gZGlzY3Vzc2lvbiBpbiBtYWlsIGxpc3Qs IHRoZW4gdGhlc2UgaGF2ZSBzdWJtaXR0ZWQgZHJhZnRzLCBhbmQgdG9waWNzIHdpdGhvdXQNCj4g ZHJhZnRzLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBBcyB5b3UgbWF5IG9ic2VydmVkLCBzbyBm YXIsIG91ciByZS1jaGFydGVyIHByb2dyZXNzIHN0aWxsIG5vdCBpbiB0aGUgcHJvY2VkdXJlLg0K PiBVbnRpbCB3ZSBoYXZlIHRoZSBuZXcgY2hhcnRlciBpbiB0aGUgcGxhY2UgYnkgdGhlIElFVEYg MTA1IHdlZWssIHdlIHN0aWxsIG5vdCBiZQ0KPiBhYmxlIHRvIGFkb3B0IGFueSBuZXcgd29yay4N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIHNlbmQgdXMgKGFuaW1hLWNoYWlycyBhdCBp ZXRmLm9yZzxodHRwczovL2lldGYub3JnLz4NCj4gPGh0dHA6Ly9pZXRmLm9yZyUzQ2h0dHBzL2ll dGYub3JnLyUzRSk+OykgcmVxdWVzdHMgZm9yIHRpbWUgc2xvdCBieSBKdWx5IDExdGgsDQo+IFRo dXJzZGF5IGFuZCBpbmNsdWRlOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBOYW1lIG9mIHRpbWUg c2xvdDoNCj4gPj4NCj4gPj4gTmFtZSBvZiBkcmFmdChzKToNCj4gPj4NCj4gPj4gVGltZSByZXF1 ZXN0ZWQ6DQo+ID4+DQo+ID4+IFByZXNlbnRlciBuYW1lKHMpOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K PiA+PiBNb3JlIGRldGFpbHMgYWJvdXQgdGhlIElFVEYgMTA1LCBNb250cmVhbCBjYW4gYmUgZm91 bmQgYXQ6DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9t ZWV0aW5ncy8xMDUvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEFnYWluLCBwcmVzZW50ZXJzIGFu ZCBkcmFmdCBhdXRob3JzIHBsZWFzZSBpbnZva2UgYWN0aXZlIGRpc2N1c3Npb25zIGluIHRoZQ0K PiBBTklNQSBsaXN0LiBNYWlsIGxpc3QgaXMgYSB2ZXJ5IGdvb2QgcGxhY2UgdG8gZGlzY3VzcyBh bmQgcmVhY2ggY29uc2Vuc3VzIG9uDQo+IHRlY2huaWNhbCBpc3N1ZXMuDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gU2hlbmcNCj4g Pj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+IEFuaW1hQGlldGYub3JnDQo+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPj4NCj4gPg0K DQo= From nobody Fri Jul 5 02:54:36 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3061200A1 for ; Fri, 5 Jul 2019 02:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl 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 mB4TSILBR0mA for ; Fri, 5 Jul 2019 02:54:31 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCB312009C for ; Fri, 5 Jul 2019 02:54:30 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 015101804CB50 for ; Fri, 5 Jul 2019 09:54:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :in-reply-to:references:message-id; s=key; bh=pVHLzfhVyXxgV4tp6K Q8iNy+NdsxCE5R13Hu+n0VMAY=; b=D8p41Me8XPXKpbqJwT6yffJtH03rWNqTob C3zpMPNBXclutjJ0V21+OgYYgb38dBz8NEiWKryATmUkEE90WJHC68bfPJkhq8GY XLPcbGQ4ckDYkPsUyNeZt+Lb7X/jlAMpZrMoD7h5EbWT+1PsVgX6dpYBmhSRyDtA hQQzKp02U= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:355:379:582:602:800:960:962:967:968:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1433:1434:1436:1437:1516:1517:1518:1535:1544:1571:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2568:2570:2631:2682:2685:2703:2741:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3622:3865:3866:3867:3868:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4119:4250:4321:4605:5007:6117:6119:6261:6298:7464:7875:7903:8603:9025:9163:10004:10128:10234:11658:12740:13139:13161:13200:13229:14827, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: hour98_443528aad3552 X-Filterd-Recvd-Size: 8464 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf12.hostedemail.com (Postfix) with ESMTPA for ; Fri, 5 Jul 2019 09:54:28 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_178585b15e62475f2d54cc0bf2686e25" Date: Fri, 05 Jul 2019 11:54:28 +0200 From: Peter van der Stok To: Anima Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <156232033209.21742.14126414526423055087.idtracker@ietfa.amsl.com> References: <156232033209.21742.14126414526423055087.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.205.201.44] Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-vanderstok-anima-constrained-join-proxy-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 09:54:35 -0000 --=_178585b15e62475f2d54cc0bf2686e25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi all, A new version has been submitted with the following changes o extended the discovery section o removed inconsistencies from the the flow diagrams o Improved readability of the examples. o stateful configurations reduced to one Greetings, peter -------- Oorspronkelijke bericht -------- ONDERWERP: New Version Notification for draft-vanderstok-anima-constrained-join-proxy-02.txt DATUM: 2019-07-05 11:52 AFZENDER: internet-drafts@ietf.org ONTVANGER: "Michael Richardson" , "Panos Kampanakis" , "Peter van der Stok" A new version of I-D, draft-vanderstok-anima-constrained-join-proxy-02.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-anima-constrained-join-proxy Revision: 02 Title: Constrained Join Proxy for Bootstrapping Protocols Document date: 2019-07-05 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-anima-constrained-join-proxy-02.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-anima-constrained-join-proxy-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanderstok-anima-constrained-join-proxy Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-anima-constrained-join-proxy-02 Abstract: This document defines a protocol to securely assign a pledge to an owner, using an intermediary node between pledge and owner. This intermediary node is known as a "constrained Join Proxy". This document extends the work of [ietf-anima-bootstrapping-keyinfra] by replacing the Circuit-proxy by a stateless constrained Join Proxy, that transports routing information. 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 --=_178585b15e62475f2d54cc0bf2686e25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi all,

A new version has been submitted with the following chan= ges

   o  extended the discovery section

 &= nbsp; o  removed inconsistencies from the the flow diagrams

   o  Improved readability of the examples.

=    o  stateful configurations reduced to one

Gree= tings,

peter


-------- Oorspronkelijke bericht --------

Onderwerp: New Version Notification for draft-vanderstok-anima-constrained-join-pr= oxy-02.txt
Datum: 2019-07-05 11:52
Afzender: internet-drafts@ietf.org
Ontvanger: "Michael Richardson" <mcr+ietf@sandelman.ca>, "Panos Kampanakis" = <pkampana@cisco.com>, "Peter van der Stok" <consultancy@vanderstok= =2Eorg>

=
A new version of I-D, draft-vanderstok-anima-constrained-join-proxy-= 02.txt
has been successfully submitted by Peter van der Stok and post= ed to the
IETF repository.

Name:     = ;   draft-vanderstok-anima-constrained-join-proxy
Revi= sion:    02
Title:       = ; Constrained Join Proxy for Bootstrapping Protocols
Document da= te:    2019-07-05
Group:      = ;  Individual Submission
Pages:     &nb= sp;  18
URL:        &nbs= p;   https://www.ietf.org/internet-drafts/draft-vanderstok-anima-constr= ained-join-proxy-02.txt
Status:      &nb= sp;  https:= //datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/
Htmlized:       https://tools.ietf.org/html/draft-vanderstok= -anima-constrained-join-proxy-02
Htmlized:    &nbs= p;  htt= ps://datatracker.ietf.org/doc/html/draft-vanderstok-anima-constrained-join-= proxy
Diff:          = ; https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-anima-constrained-join-proxy-02=

Abstract:
   This document defines a= protocol to securely assign a pledge to an
   owner, = using an intermediary node between pledge and owner.  This
 = ;  intermediary node is known as a "constrained Join Proxy".

   This document extends the work of [ietf-anima-bo= otstrapping-keyinfra]
   by replacing the Circuit-prox= y by a stateless constrained Join Proxy,
   that trans= ports routing information.

      = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; 


Please note that it may take a couple of minute= s from the time of submission
until the htmlized version and diff are= available at tools.ietf.org.

The IETF Secretariat
--=_178585b15e62475f2d54cc0bf2686e25-- From nobody Fri Jul 5 03:10:01 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B401200B5 for ; Fri, 5 Jul 2019 03:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=FxHFrSCx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UtBOc0w5 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 oOZ7KWH_IhPZ for ; Fri, 5 Jul 2019 03:09:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337CC12009C for ; Fri, 5 Jul 2019 03:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2458; q=dns/txt; s=iport; t=1562321396; x=1563530996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C2yKGoRFdnnyHGjqGJmupaN/8OT0xS+qCu/bILVM8uY=; b=FxHFrSCxkEAjF6eLz0CYcUc/12Iwv8UikgfhZvfDCeUqZHoXK8rCKEeT FOGooFefThigJNGZUGHjdbhXoDLCZiEZx0LSJ5SOtv0Be5G0epuBI1pSW a8zTn0E5BHLWvWzrmgKlnju81ftSaIaGsD9DGGAvUDMXPzM3xDnl4/f2Q A=; IronPort-PHdr: =?us-ascii?q?9a23=3A6hOotBcBQx5y8CES9gWIU9b3lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aCIgHclGfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAABYIR9d/49dJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgUNQA2pVIAQLKIdjA4RSiXiCW4lNjXm?= =?us-ascii?q?BLoEkA1QJAQEBDAEBJQgCAQGBS4J1AoIuIzQJDgEDAQEEAQECAQVtijcMhUo?= =?us-ascii?q?BAQEBAgESKAYBATUCAQsEAgEIEQQBAQEeECERHQgCBAENBQgagwGBagMODwE?= =?us-ascii?q?CDJosAoE4iGCCI4J5AQEFgUZBgxANC4ISCYE0AYteF4FAP4ERRoJMPoIaRwI?= =?us-ascii?q?DAYFfgzqCJqoJQAkCgheGVok6hA6CLGyKPooijTCHP4FzjgkCBAIEBQIOAQE?= =?us-ascii?q?FgVA4gVhwFYMnCYI4N4M6hRSFP3KBKY1iAQE?= X-IronPort-AV: E=Sophos;i="5.63,454,1557187200"; d="scan'208";a="589255863" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2019 10:09:54 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x65A9sCn022322 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jul 2019 10:09:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 05:09:53 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 06:09:52 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 5 Jul 2019 05:09:52 -0500 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=xnbR7tf3ps5vLneq8rx5GFIvvISHfTwLkfn3hsVRlh8=; b=UtBOc0w5Tfhjau8+dc2KuWAK98jkfQdG7fJQ3fNI7fYLyzFFMY5msRE5D1gomrPQmJTX/MgxXhWEqwhCPR754taompFB8Dm8/L+rKeX52ffyvNh5zdO9jxEFr6bBs6iPtPvCJMEI2AZeG1Az9Jh+1NuzPNCpf5LepqVpLuJS9sQ= Received: from SN6PR11MB3389.namprd11.prod.outlook.com (52.135.110.33) by SN6PR11MB3280.namprd11.prod.outlook.com (52.135.109.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Fri, 5 Jul 2019 10:09:51 +0000 Received: from SN6PR11MB3389.namprd11.prod.outlook.com ([fe80::d8c6:4076:1bc5:a651]) by SN6PR11MB3389.namprd11.prod.outlook.com ([fe80::d8c6:4076:1bc5:a651%6]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 10:09:51 +0000 From: "Owen Friel (ofriel)" To: Michael Richardson , "anima@ietf.org" CC: Rifaat Shekh-Yusef Thread-Topic: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt Thread-Index: AQHVMQb4X6tqrYd/KEe6IqDPJ/uJ2Ka3rneAgAHMuQCAAlKfEA== Date: Fri, 5 Jul 2019 10:09:51 +0000 Message-ID: References: <156209339375.23780.16389385862360970000.idtracker@ietfa.amsl.com> <7216.1562192902@localhost> In-Reply-To: <7216.1562192902@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1250:a17c:7d2f:424f:dab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa077c18-6b0a-42ee-64c4-08d70130eb70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB3280; x-ms-traffictypediagnostic: SN6PR11MB3280: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(396003)(346002)(39860400002)(51444003)(189003)(199004)(13464003)(53546011)(6506007)(6116002)(81156014)(33656002)(86362001)(8676002)(55016002)(9686003)(6436002)(99286004)(11346002)(14454004)(6306002)(446003)(5660300002)(81166006)(53936002)(68736007)(76176011)(71190400001)(486006)(966005)(6246003)(102836004)(25786009)(2501003)(71200400001)(229853002)(8936002)(476003)(15650500001)(76116006)(74316002)(52536014)(7696005)(4326008)(2906002)(46003)(316002)(66946007)(66446008)(66476007)(14444005)(110136005)(305945005)(64756008)(186003)(73956011)(7736002)(478600001)(66556008)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3280; H:SN6PR11MB3389.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iB5Xz+LjJpa9hxQVfvqvgmytG6iVjHBbQMt5+IErBGb3J4fQvxsXpbiZfZfijkC4Q6QCfuH3LHESrtrniiFy4bn1wD+X/MU3HTAY/ZzccYeRHMcW2z40uGZCJevldjDUrh2wv21FC2kuLc8hJNpgJKG1Vk4emd1yFITFIXgs+pH4Q74kvkBi20v7EgJAXyz+rvCYJHrn7kKBPToEL2DebU/yoBxqynYn82Di19qikPGml79849IFjHs2dfOfP0S2he604BEQDNsJzaQtbGUiVg227ptL9V8SeOGeTsTEcCvzUk1BeNlhVnVPfkngYPT+dRzrYhtiVQ1ErEGo3z9VRJhkG5aLPgUKFsCXZYmft4GDkWj6PDH+E4K5ZeHY0jq+v2GbN+SefO+jtdSVvYUnjIWV+5aC7CvhNH8k+y1LLNQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa077c18-6b0a-42ee-64c4-08d70130eb70 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 10:09:51.4455 (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: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3280 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 10:09:59 -0000 -----Original Message----- From: Anima On Behalf Of Michael Richardson Sent: 03 July 2019 23:28 To: anima@ietf.org; Owen Friel (ofriel) Cc: Rifaat Shekh-Yusef Subject: Re: [Anima] FW: New Version Notification for draft-friel-acme-inte= grations-01.txt Owen Friel (ofriel) wrote: > This early draft > https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ cover= s > how BRSKI could potentially be integrated with an ACME CA for cert > issuance. I read it. While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I= 'm not actually sure what it means from a standards point of view. [ofriel] Yes, this could maybe be Informational rather than std track. As c= urrently written, there are no changes required to BRSKI, EST or ACME draft= s, so it really is informational on how to stitch these things together. On= e of the interesting things is possisble use of ACME for subdomain certs, w= hich the flows for EST, BRSKI and TEAP illustrate, as this is a nice signal= ling optimisation for scaling to large number of clients. My code base does not connect the RA to LetsEncrypt, but rather uses LetsEn= crypt to produce IDevIDs from a provisioning process. I think that you have a problem in STEP 2 (section 3), and STEP 3 (section = 4), STEP 3 (section 5). In each place where you post a CSR, you omit the part where you get the CSR= attributes. At some point the pledge needs to learn about what the delegat= ed domain is ("domain.com"). [ofriel] Sure, it doesn't include all the BRSKI bits. Its also left as a to= do exactly how the client should determine its domain for inclusion in the = CSR if it only has its IDevID to start with. In section 4, the figures (which need to be numbered, btw), is labelled a P= ledge, but since there is no BRSKI, it should "Client" [ofriel] For sure, loads of minor nits in -01. > Related work is > https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-at= testation/, > which covers how ACME could be used to issue device certs, but does n= ot > use BRSKI. We are currently discussing offline with Rifaat how we cou= ld > potentially integrate both approaches. I'll read this. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sat Jul 6 19:20:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B606120119 for ; Sat, 6 Jul 2019 19:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KzEqG0fXYWfz for ; Sat, 6 Jul 2019 19:20:18 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69081200A3 for ; Sat, 6 Jul 2019 19:20:18 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id l21so1922263pgm.3 for ; Sat, 06 Jul 2019 19:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M9n5eiPBemQV/O6ezfgFECeK3muaQ3lTx60zpOjFr7Y=; b=qiH1TJPVmd8eBq8HHKILXrGR7W7ba8T9m5cgCurzEaHd6/aAt0d3llOoPHK9kiVsh9 qdCh7YvYceysSlUxruBoAsAgmIp18lM+ZrrknwLFQqcX1W6u9cgdHQQLaoL2fNpXIZVK 16XkB5DRVoF+ivGk17AR9XK02klaM48YHKFMaSm7GycLi7hsk56VjtDM2jzKXOTFrtKJ KogOa1+XirEVcOukeSj18WrUG+VYe77XuC+S/tw4IjI2t2Nw+MUISep32qMR8dJEHGwq 3uXlQX5ylUrRiXrWoo15gDAT/K/YevFpS9Wrxep6lYQpjqPDhgZCkffQy+xBwNPiz9CR 12TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=M9n5eiPBemQV/O6ezfgFECeK3muaQ3lTx60zpOjFr7Y=; b=XdJ8icQyAC2AjDpWd1ztuQGHpuksT2MOB5i/4M0KGaC40dZF8+H3t7Q/hR+WAmtRrr yEhlkWqBC/CdjrrKSepRQLLi/ph+xv3iEqXWaSdDDA8Owwgm265FXhHfXJlGodIkMy1f tOAq0AzpE5uFP6ekMjMeWGgbImNCduAJGS+jTTB369K26hYgqOkjzynHCljASo15YvSp nBdU6Jy7zstXc0/rb9WPNpB1nkCXzF5rwl1UaQB/NZl+ArLztxPvBoIkYoC+pskQe7g1 ZW1oaeQFhKg+2pGlHtyYSvmD15v1YIMVGoPB0f2apUU/Kgi6Z29pboRI6a+ka2mvZlwR sJow== X-Gm-Message-State: APjAAAV+9mi+BfeWp1Jgox/KIwcNdx7PXlyGh2bATep+r0eKFcm5XsER /pfZOfIR2jVF8Kovohde2QQWs3xj X-Google-Smtp-Source: APXvYqz5Ui13KkilSyGxusw8gnNBxiqVCxs4Q3Zh6QGboejeiIyNoEm/zl5AuvUutDEVUhBYOmiqBA== X-Received: by 2002:a17:90a:ff17:: with SMTP id ce23mr14676818pjb.47.1562466017792; Sat, 06 Jul 2019 19:20:17 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id p2sm16586850pfb.118.2019.07.06.19.20.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 19:20:17 -0700 (PDT) References: <156246579536.3255.13533355152898289868@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <156246579536.3255.13533355152898289868@ietfa.amsl.com> Message-ID: <917d6fc9-d76a-3071-1017-0fedb67ef170@gmail.com> Date: Sun, 7 Jul 2019 14:20:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <156246579536.3255.13533355152898289868@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-asa-guidelines-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 02:20:22 -0000 A small mainly editorial update... -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-asa-guidelines-07.txt Date: Sat, 06 Jul 2019 19:16:35 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Autonomic Service Agents Authors : Brian Carpenter Laurent Ciavaglia Sheng Jiang Pierre Peloso Filename : draft-carpenter-anima-asa-guidelines-07.txt Pages : 24 Date : 2019-07-06 Abstract: This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. It is based on the Autonomic Network Infrastructure outlined in the ANIMA reference model, making use of the Autonomic Control Plane and the Generic Autonomic Signaling Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-asa-guidelines/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines-07 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-asa-guidelines-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-asa-guidelines-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 8 03:12:10 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6D120129 for ; Mon, 8 Jul 2019 03:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FQBh3XJsyuAP for ; Mon, 8 Jul 2019 03:12:06 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0585D12010F for ; Mon, 8 Jul 2019 03:12:05 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x68AC30H025614 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 8 Jul 2019 12:12:03 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x68AC3v4016310 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 8 Jul 2019 12:12:03 +0200 Received: from DENBGAT9ERIMSX.ww902.siemens.net (139.22.70.138) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 12:12:03 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.197]) by DENBGAT9ERIMSX.ww902.siemens.net ([139.22.70.138]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 12:12:02 +0200 From: "Fries, Steffen" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-fries-anima-brski-async-enroll-01.txt Thread-Index: AQHVNXRQSYuO9dRAP0yIPUaI9jpKqabAf37g Date: Mon, 8 Jul 2019 10:12:01 +0000 Message-ID: References: <156258004189.1093.17800160134532385145.idtracker@ietfa.amsl.com> In-Reply-To: <156258004189.1093.17800160134532385145.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-fries-anima-brski-async-enroll-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:12:09 -0000 SGksDQoNCldlIHByb3ZpZGVkIGFuIHVwZGF0ZSBvbiB0aGUgQlJTS0ktQUUgZHJhZnQuIFRoZSB1 cGRhdGUgYWRkcmVzc2VzIG1hbnkgb2YgdGhlICJUQkQiIHBsYWNlcyBmcm9tIHRoZSAwMCB2ZXJz aW9uLiBTcGVjaWZpY2FsbHkgaXQgcHJvdmlkZXMgdGhlIHVzZSBjYXNlIGRlc2NyaXB0aW9uIGFz IHdlbGwgYXMgdGhlIHBvdGVudGlhbCBjYWxsIGZsb3cuIFdlIGFsc28gc3RhcnRlZCBhIG1hcHBp bmcgdG8gZXhpc3RpbmcgZW5yb2xsbWVudC4gDQoNCkkgd2lsbCB3cml0ZSBhIHNlcGFyYXRlIGVt YWlsIGFza2luZyBmb3IgYSBwcmVzZW50YXRpb24gc2xvdCBkdXJpbmcgdGhlIG5leHQgSUVURiBt ZWV0aW5nDQoNCkJlc3QgcmVnYXJkcw0KU3RlZmZlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IA0KU2VudDogTW9udGFnLCA4LiBKdWxpIDIwMTkgMTI6MDENClRvOiBFbGlvdCBMZWFy IDxsZWFyQGNpc2NvLmNvbT47IEZyaWVzLCBTdGVmZmVuIChDVCBSREEgQ1NUKSA8c3RlZmZlbi5m cmllc0BzaWVtZW5zLmNvbT47IEJyb2NraGF1cywgSGVuZHJpayAoQ1QgUkRBIENTVCBTRUEtREUp IDxoZW5kcmlrLmJyb2NraGF1c0BzaWVtZW5zLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtZnJpZXMtYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsLTAxLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmllcy1hbmltYS1icnNraS1hc3lu Yy1lbnJvbGwtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0ZWZm ZW4gRnJpZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtZnJpZXMtYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJ U3VwcG9ydCBvZiBhc3luY2hyb25vdXMgRW5yb2xsbWVudCBpbiBCUlNLSQ0KRG9jdW1lbnQgZGF0 ZToJMjAxOS0wNy0wOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjMN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZnJpZXMtYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsLTAxLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyaWVzLWFuaW1hLWJyc2tp LWFzeW5jLWVucm9sbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZnJpZXMtYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsLTAxDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1mcmllcy1hbmlt YS1icnNraS1hc3luYy1lbnJvbGwNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZnJpZXMtYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsLTAxDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgYW4gZW5oYW5jZW1lbnQgb2Yg YXV0b21hdGVkIGJvb3RzdHJhcHBpbmcgb2YNCiAgIGEgcmVtb3RlIHNlY3VyZSBrZXkgaW5mcmFz dHJ1Y3R1cmUgKEJSU0tJKSB0byBvcGVyYXRlIGluIGRvbWFpbnMNCiAgIGZlYXR1cmluZyBubyBv ciBvbmx5IHRpbWVseSBsaW1pdGVkIGNvbm5lY3Rpdml0eSB0byBiYWNrZW5kIHNlcnZpY2VzDQog ICBvZmZlcmluZyBlbnJvbGxtZW50IGZ1bmN0aW9uYWxpdHksIHNwZWNpZmljYWxseSBhIFB1Ymxp YyBLZXkNCiAgIEluZnJhc3RydWN0dXJlIChQS0kpLiAgSW4gdGhlIGNvbnRleHQgb2YgZGVwbG95 aW5nIG5ldyBkZXZpY2VzIHRoZQ0KICAgZGVzaWduIG9mIEJSU0tJIGFsbG93cyBmb3Igb25saW5l IChzeW5jaHJvbm91cyBvYmplY3QgZXhjaGFuZ2UpIGFuZA0KICAgb2ZmbGluZSBpbnRlcmFjdGlv bnMgKGFzeW5jaHJvbm91cyBvYmplY3QgZXhjaGFuZ2UpIHdpdGggYQ0KICAgbWFudWZhY3R1cmVy J3MgYXV0aG9yaXphdGlvbiBzZXJ2aWNlLiAgRm9yIHRoaXMgaXQgdXRpbGl6ZXMgYSBzZWxmLQ0K ICAgY29udGFpbmVkIHZvdWNoZXIgdG8gdHJhbnNwb3J0IHRoZSBkb21haW4gY3JlZGVudGlhbHMg YXMgYSBzaWduZWQNCiAgIG9iamVjdCB0byBlc3RhYmxpc2ggYW4gaW5pdGlhbCB0cnVzdCBiZXR3 ZWVuIHRoZSBwbGVkZ2UgYW5kIHRoZQ0KICAgZGVwbG95bWVudCBkb21haW4uICBUaGUgY3VycmVu dGx5IHN1cHBvcnRlZCBlbnJvbGxtZW50IHByb3RvY29sIGZvcg0KICAgcmVxdWVzdCBhbmQgZGlz dHJpYnV0aW9uIG9mIGRlcGxveW1lbnQgZG9tYWluIHNwZWNpZmljIGRldmljZQ0KICAgY2VydGlm aWNhdGVzIHByb3ZpZGVzIG9ubHkgbGltaXRlZCBzdXBwb3J0IGZvciBhc3luY2hyb25vdXMgUEtJ DQogICBpbnRlcmFjdGlvbnMuICBUaGlzIG1lbW8gbW90aXZhdGVzIHRoZSBlbmhhbmNlbWVudCBv ZiBzdXBwb3J0aW5nDQogICBzZWxmLWNvbnRhaW5lZCBvYmplY3RzIGZvciBjZXJ0aWZpY2F0ZSBt YW5hZ2VtZW50IGJ5IHVzaW5nIGFuDQogICBhYnN0cmFjdCBub3RhdGlvbi4gIFRoaXMgYWxsb3dz IG9mZi1zaXRlIG9wZXJhdGlvbiBvZiBQS0kgc2VydmljZXMNCiAgIG91dHNpZGUgdGhlIGRlcGxv eW1lbnQgZG9tYWluIG9mIHRoZSBwbGVkZ2UuICBUaGlzIGFkZHJlc3Nlcw0KICAgc3BlY2lmaWNh bGx5IHNjZW5hcmlvcywgaW4gd2hpY2ggdGhlIGZpbmFsIGF1dGhvcml6YXRpb24gb2YNCiAgIGNl cnRpZmljYXRpb24gcmVxdWVzdCBvZiBhIHBsZWRnZSBjYW5ub3QgYmUgbWFkZSBpbiB0aGUgZGVw bG95bWVudA0KICAgZG9tYWluIGFuZCBpcyB0aGVyZWZvcmUgZGVsZWdhdGVkIHRvIGEgb3BlcmF0 b3IgYmFja2VuZC4gIFRoZSBnb2FsIGlzDQogICB0byBlbmFibGUgdGhlIHVzYWdlIG9mIGV4aXN0 aW5nIGFuZCBwb3RlbnRpYWxseSBuZXcgUEtJIHByb3RvY29scw0KICAgc3VwcG9ydGluZyBzZWxm LWNvbnRhaW5tZW50IGZvciBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50Lg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Jul 8 03:21:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A120120111; Mon, 8 Jul 2019 03:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JONs7a9MOqnp; Mon, 8 Jul 2019 03:21:03 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDC4120110; Mon, 8 Jul 2019 03:21:03 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x68AKqAX003095 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Jul 2019 12:20:52 +0200 Received: from DEFTHW99ER8MSX.ww902.siemens.net (defthw99er8msx.ww902.siemens.net [139.22.70.73]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x68AKCoC003235 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Jul 2019 12:20:52 +0200 Received: from DENBGAT9ER1MSX.ww902.siemens.net (139.22.70.87) by DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 12:20:17 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.197]) by DENBGAT9ER1MSX.ww902.siemens.net ([139.22.70.87]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 12:20:16 +0200 From: "Fries, Steffen" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" , Eliot Lear , "Brockhaus, Hendrik" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wJcBnJA Date: Mon, 8 Jul 2019 10:20:16 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.12] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337826FE3491DENBGAT9EJ5MSXw_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:21:05 -0000 --_000_E6C9F0E527F94F4692731382340B337826FE3491DENBGAT9EJ5MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sheng, I would like to ask for a timeslot on: Name of time slot: BRSKI-AE (BRSKI with support for asynchronous enrollment= ) Name of draft(s): draft-fries-anima-brski-async-enroll-01.txt Time requested: 10min Presenter name(s): Eliot Lear The draft covers the support of asynchronous enrollment for situations in w= hich there is no or only a temporary connection to the CA issuing the certi= ficates. The approach uses self contained objects to bind the initial pledg= e authentication using the IDevID credential to the certification request. In comparison to version 00 this version enhances the application use case = description as well as the technical approach. It also starts the mapping t= o existing enrollment protocols. Best regards Steffen From: Anima On Behalf Of Sheng Jiang Sent: Mittwoch, 26. Juni 2019 11:59 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs' email. Please note that ema= il to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_E6C9F0E527F94F4692731382340B337826FE3491DENBGAT9EJ5MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sheng,

 

I would like to ask for a timeslot on:=

 

Name of time slot: BRSKI-AE (BRSKI wit= h support for asynchronous enrollment)

Name of draft(s): draft-fries-anima-br= ski-async-enroll-01.txt

Time requested: 10min

Presenter name(s): Eliot Lear

 

The draft covers the support of asynch= ronous enrollment for situations in which there is no or only a temporary c= onnection to the CA issuing the certificates. The approach uses self contained objects to bind the initial pledge authen= tication using the IDevID credential to the certification request.

In comparison to version 00 this versi= on enhances the application use case description as well as the technical a= pproach. It also starts the mapping to existing enrollment protocols.

 

Best regards

Steffen

 

From: Anima <anima-bounces@ietf.org> On Behalf Of Sheng Jiang
Sent: Mittwoch, 26. Juni 2019 11:59
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

 = 

Hi, all a=
nima,
&nbs=
p;
We have b=
een allocated two sessions of 2 + 1.5 hour for the ANIMA WG meeting for=
 IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session I. W=
e are now starting to collect agenda items for the sessions. Please send yo=
ur request for agenda by July 11th, Thursday, to anima-chairs@ietf.org and both chairs’ email. Plea=
se note that email to a single chair may cause single failure.
&nbs=
p;
For this =
coming meeting, we would like have the 1.5 hour session for BRSHI and Vouch=
er relevant topics and the 2 hour session for the others. As normal, the pr=
iority among these non-charter work items would be: these that have active =
discussion in mail list, then these have submitted drafts, and topics witho=
ut drafts.
&nbs=
p;
As you ma=
y observed, so far, our re-charter progress still not in the procedure. Unt=
il we have the new charter in the place by the IETF 105 week, we still not =
be able to adopt any new work.
&nbs=
p;
Please se=
nd us (anima-chairs at ietf.org<https://ietf.org/>;) =
requests for time slot by July 11th, Thursday and include:
&nbs=
p;
Name of t=
ime slot:
Name of d=
raft(s):
Time requ=
ested:
Presenter=
 name(s):
&nbs=
p;
More deta=
ils about the IETF 105, Montreal can be found at:
&nbs=
p;
https://www.ietf.org/how/meetin=
gs/105/
&nbs=
p;
Again, pr=
esenters and draft authors please invoke active discussions in the ANIMA li=
st. Mail list is a very good place to discuss and reach consensus on techni=
cal issues.
&nbs=
p;
Best rega=
rds,
&nbs=
p;
Sheng
--_000_E6C9F0E527F94F4692731382340B337826FE3491DENBGAT9EJ5MSXw_-- From nobody Mon Jul 8 06:23:24 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46370120221; Mon, 8 Jul 2019 06:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=pXVMhfZX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BMky019S 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 q0jWObyf3frw; Mon, 8 Jul 2019 06:23:05 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1EC1201EB; Mon, 8 Jul 2019 06:23:05 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B8AEC6A9; Mon, 8 Jul 2019 09:23:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 08 Jul 2019 09:23:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 NLkyuuqPpcpQ4Vo5hITJKv4INK6HpLQqP/1l/XTPTc=; b=pXVMhfZXRlkqNftsJ S+4EMuke4UkSANtlExUuUHl9fKbd4gDUmaLTfZhmBaFZg2RoXXtH/W3YZfZ7yNVV ueyrbSBs7FdQeKIeo4eg4hTG7FIA5DGaTQDUGoPYkYb+y02TKf4fIuJ9gSXY2p5L nXBLWDSxa/8gvNM/FGPSzlMPtyled+F6CjWeXgV6zLjljSHGzFHu5Unh/oH/GZe5 LPdwzsqQhVE8eK8uUsojUt6mEFtZF5pdtB9u8uxsjzEXX5+LOEX6NdJFJmqqAiSF K7wNp/DPnUCnpTxFUi0OlglRjcSv419JJ0oySo2n4D34vP0ZQO5C8UPAuejTaWU1 1rKzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6NLkyuuqPpcpQ4Vo5hITJKv4INK6HpLQqP/1l/XTP Tc=; b=BMky019STXQ9SqR72ZLwP2IUDbzZd2uu+NrEwdqARLI33epTzTl8FNBbw L+K06VbrEH2PGkGz1I/vEKj/9TIDglE3cfUxIQDZzTWm7kFxKOkfW+zeNw3viY9t 0oQ7etofRVIjwC/lm1SqKc9x7KfDNb8hr4JgeWavacL5HECtbizfooc1kPRXyO/h SOM0nRTqW/zwNdtjDSm8TxbzK5LoH53AirGW88kdhTluJHVO55DZt7diTS3fjFBF +ANIk2A3Fug9z0+kTymcrjMdfn+mwXQauxehU9OjJosxMu//hUnbnUsrcpeJISUe N0D4wBrscOqs7W3CtVhkPBvcead/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgedtgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejgeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 684B2380076; Mon, 8 Jul 2019 09:23:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92999EAE8E@NKGEML515-MBS.china.huawei.com> Date: Mon, 8 Jul 2019 09:23:01 -0400 Cc: Brian E Carpenter , IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92999EAE8E@NKGEML515-MBS.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:23:17 -0000 Hi Sheng, > On Jul 3, 2019, at 10:39 AM, Sheng Jiang = wrote: >=20 > Hi, Alissa, >=20 > Thanks for your kindly response. I have made a new version (2.0.8) = according to your feedback. Explanation in lines below. >=20 > Please see https://trac.ietf.org/trac/anima/wiki/Recharter2019 >=20 >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Wednesday, July 3, 2019 5:13 AM >> To: Brian E Carpenter >> Cc: IESG ; anima-chairs@ietf.org; anima@ietf.org >> Subject: Re: [Anima] Alissa Cooper's Block on = charter-ietf-anima-01-05: (with >> BLOCK and COMMENT) >>=20 >> Hi all, >>=20 >> I=E2=80=99ve been discussing this on my weekly call with the OPS ADs = for the last >> couple of weeks and based on the call that we had earlier today my >> understanding is that now would be a good time to re-review. >>=20 >> Regarding this text: "New work items will be adopted by the WG only = if their >> contributors target them to enter WG last call within a number of = IETF meeting >> cycles agreed by the AD.=E2=80=9D >>=20 >> I still don=E2=80=99t get this. It is a very common case that = contributors think their >> drafts are going to get through to WGLC in X cycles, and then they = end up >> taking 2X or 10X because some new person wanders into the WG or some >> other work starts up in another WG that has an intersection with the = work or >> someone changes jobs or any manner of other things. The WG needs >> milestones with dates, preferably at the point of approving the = re-charter. >> Those might be missed too, but there might as well not be two sets of = markers >> laid down that are potentially going to be missed rather than one = set. >=20 > I have just deleted the sentence. It's something the chairs can do = during the WG management process. We tried to give draft owners some = pressure not to be too slow by adding these text. I do agree this should = not be so rigid as these text. So, let's take it out and the chairs will = monitor the progress of WG drafts closely. Thanks. >=20 >> Regarding the =E2=80=9Cindicative scope of possible work items=E2=80=9D= =E2=80=94 this doesn=E2=80=99t >> address my concern about the WG=E2=80=99s scope. This charter is in = contrast to the >> current ANIMA charter, which says: "The initial set of work items is = limited to >> the above list to stay focused and avoid 'boiling the ocean=E2=80=99.=E2= =80=9D I don=E2=80=99t see the >> rationale for not carrying that forward to the next set of specific = work items >> where WG participants have demonstrated interest and intent to carry = the >> work forward. If that is the list of initial milestone topics listed, = then limiting to >> that makes sense to me. >=20 > I have added a specific list of work items into the initial milestone = list.=20 >=20 > Obviously, this initial milestone list does NOT cover all the topics = that WG participants have showed interests and willingness to work on. = The purpose to have this description of "indicative scope of possible = work items=E2=80=9D are actually two: A, limit the potential work items = not to be too wide I think my disconnect here is that the list doesn=E2=80=99t actually = limit the WG=E2=80=99s scope because it uses the language =E2=80=9Cindicat= ive scope of possible work items=E2=80=9D and =E2=80=9Cincluding but not = limited to.=E2=80=9D The five areas of work in this list seem broad and = large enough to keep the WG busy for quite some time. For the charter to = effectively limit the scope I think it would need to say =E2=80=9CThe = scope of work items is limited to:=E2=80=9D or something like that. Thanks, Alissa > , otherwise, people may take anything has the work "automatic" to the = WG; B, to give the chairs a little bit flexibility to adopt new works = beyond the initial milestone list. We try to avoid the problem that = every time a new draft comes up, it may become a charter revision, = particularly, giving the current re-charting process have taken us many = months. >=20 > Best regards, >=20 > Sheng >=20 >> Thanks, >> Alissa >>=20 >>> On Jun 10, 2019, at 9:02 PM, Brian E Carpenter >> wrote: >>>=20 >>> Hi all, >>>=20 >>> I've taken the liberty of posting an update to the draft charter at >>> https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried to >>> respond to all the IESG comments, and in particular: >>>=20 >>> (a) I deleted Intent from the summarised reference model framework, >>> since the reference model doesn't usefully define Intent. >>>=20 >>> (b) I tried to make the statement about workload throttling more >>> implementable. >>>=20 >>> (c) I still think that the laundry list of *possible* work items is >>> useful (it helps to define the scope) but I've tried make it clear >>> that it is only the "indicative scope of possible work items". >>> It really isn't mission creep; all the items mentioned relate = directly >>> to the ANI and AF topics. >>>=20 >>> (d) I intentionally removed the reference to not covering machine >>> learning and AI. It isn't suggested anywhere in the reference model, >>> so why even mention it? >>>=20 >>> (e) I fixed nits and tuned the wording in several places. >>>=20 >>> I hope this helps. We really need a new charter before Montreal. >>> WG Chairs and AD, over to you... >>>=20 >>> Regards >>> Brian Carpenter >>>=20 >>> On 02-May-19 08:39, Brian E Carpenter wrote: >>>> Hi Alissa, >>>>=20 >>>> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: >>>> ... >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> BLOCK: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> (1) "Acceptance of work items by the WG will be = scheduled/throttled >>>>> so that contributors can target them to enter WG last call after = not >>>>> more than a number of IETF meeting cycles agreed by the AD." >>>>>=20 >>>>> I don't understand the implications of this. What happens if the >>>>> adopted work items have not entered WGLC after the agreed number = of >>>>> cycles? If the answer is anything other than "the WG abandons the >>>>> work," I don't understand how this is a throttling mechanism. A >>>>> throttling mechanism would need an explicit limit on the number of >> adopted work items at any one time, I think. >>>>=20 >>>> I agree that the text is a bit illogical. In a sense it's >>>> unnecessary, because every WG should be matching its workload to = its >>>> capacity. Maybe that's all we should say, rather than trying to = describe a >> slightly vague algorithm? >>>>=20 >>>>> (2) The proposed work items is a very large and somewhat unbounded >>>>> list of items, whereas the purpose of writing a charter is to = scope >>>>> the work of the WG and hopefully set out a realistic work plan = that >>>>> will be accompanied by deployment. For a WG that has produced 5 >>>>> documents in the last 5 years, I think the charter needs to more >>>>> narrowly focus on the most highly prioritized work items. Once = those >>>>> are nearing completion, it seems as though evaluation of what is >>>>> needed next based on deployment experience would then dictate the = next >> set of items for another re-charter. >>>>=20 >>>> I think the point here is that now that the relatively small number >>>> of infrastructure documents are almost finished, the next stage = opens >>>> up the possibilities for a much wider range of work that builds on >>>> the infrastructure. The priorities aren't even obvious. So this = goes >>>> with the previous point, and to quite some extent the criteria will >>>> be whether the WG has capacity more than which topic has priority. >>>>=20 >>>> That's why there's a bucket list of work items and a short list of >>>> immediate milestones. >>>>=20 >>>> Would this help? >>>>=20 >>>> s/Proposed work items include.../Possible work items include.../ >>>>=20 >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> COMMENT: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> It would be good to see milestones with dates before this gets = approved. >>>>>=20 >>>>> I think this charter would benefit from an English edit pass = before going >> out for external review. >>>>=20 >>>> I'll volunteer, when the open issues have been resolved. >>>>=20 >>>>> What is "compounding environment"? >>>>=20 >>>> An excellent question. >>>>=20 >>>> Brian >>>>=20 >=20 From nobody Mon Jul 8 09:41:00 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886DA120046; Mon, 8 Jul 2019 09:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156260404948.820.11193114494544035961@ietfa.amsl.com> Date: Mon, 08 Jul 2019 09:40:49 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:40:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Voucher Artifacts for Bootstrapping Protocols Authors : Michael Richardson Peter van der Stok Panos Kampanakis Filename : draft-ietf-anima-constrained-voucher-05.txt Pages : 41 Date : 2019-07-08 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-est] protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-05 https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 9 19:38:52 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A2F120141; Tue, 9 Jul 2019 19:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QsTq9RogYW49; Tue, 9 Jul 2019 19:38:40 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A5E12029D; Tue, 9 Jul 2019 19:38:40 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 96A113CB9CDBA6E60000; Wed, 10 Jul 2019 03:38:38 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 03:38:38 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Wed, 10 Jul 2019 10:38:31 +0800 From: Sheng Jiang To: Alissa Cooper CC: Brian E Carpenter , IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) Thread-Index: AQHVMRrqZSr/q4kRhUGo8D1qiq9RK6a4jzsAgAeo+oCAAvO18A== Date: Wed, 10 Jul 2019 02:38:30 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999EE42A@NKGEML515-MBS.china.huawei.com> References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92999EAE8E@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 02:38:51 -0000 SGksIEFsaXNzYSwNCg0KSSBoYXZlIG1hZGUgYSBuZXcgdmVyc2lvbiAoMi4wLjkpIGFjY29yZGlu ZyB0byB5b3VyIGxhdGVzdCBmZWVkYmFjay4gSSBoYXZlIG1hZGUgdGhlIGJlbG93IGNoYW5nZSBh bmQgZGVsZXRlZCB0aGUgb25seSAiaW5jbHVkaW5nIGJ1dCBub3QgbGltaXRlZCB0b+KAnSBpbiB0 aGUgcHJldmlvdXMgMi4wLjggdmVyc2lvbi4NCg0KT0xEOiBUaGUgaW5kaWNhdGl2ZSBzY29wZSBv ZiBwb3NzaWJsZSB3b3JrIGl0ZW1zIGluY2x1ZGVzOg0KDQpORVc6IFRoZSBzY29wZSBvZiBwb3Nz aWJsZSB3b3JrIGl0ZW1zIGFyZSAoYWRkaXRpb25hbCB3b3JrcyBhcmUgc3ViamVjdCB0byBleHRy YSBhcHByb3ZhbCBmcm9tIHRoZSByZXNwb25zaWJsZSBBRCk6DQoNClRoZSBsYXRlc3QgY2hhbmdl IGhhcyBiZWVuIHVwbG9hZCBvbiB3aWtpDQoNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2Fu aW1hL3dpa2kvUmVjaGFydGVyMjAxOQ0KDQpNYW55IHRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLA0K DQpTaGVuZw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsaXNzYSBD b29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0NCj4gU2VudDogTW9uZGF5LCBKdWx5IDA4 LCAyMDE5IDk6MjMgUE0NCj4gVG86IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+ DQo+IENjOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPjsg SUVTRyA8aWVzZ0BpZXRmLm9yZz47DQo+IGFuaW1hLWNoYWlyc0BpZXRmLm9yZzsgYW5pbWFAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBbmltYV0gQWxpc3NhIENvb3BlcidzIEJsb2NrIG9uIGNo YXJ0ZXItaWV0Zi1hbmltYS0wMS0wNTogKHdpdGgNCj4gQkxPQ0sgYW5kIENPTU1FTlQpDQo+IA0K PiBIaSBTaGVuZywNCj4gDQo+ID4gT24gSnVsIDMsIDIwMTksIGF0IDEwOjM5IEFNLCBTaGVuZyBK aWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpLCBBbGlzc2Es DQo+ID4NCj4gPiBUaGFua3MgZm9yIHlvdXIga2luZGx5IHJlc3BvbnNlLiBJIGhhdmUgbWFkZSBh IG5ldyB2ZXJzaW9uICgyLjAuOCkgYWNjb3JkaW5nIHRvDQo+IHlvdXIgZmVlZGJhY2suIEV4cGxh bmF0aW9uIGluIGxpbmVzIGJlbG93Lg0KPiA+DQo+ID4gUGxlYXNlIHNlZSBodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9hbmltYS93aWtpL1JlY2hhcnRlcjIwMTkNCj4gPg0KPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxp c3NhQGNvb3BlcncuaW5dDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzLCAyMDE5IDU6MTMg QU0NCj4gPj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b20+DQo+ID4+IENjOiBJRVNHIDxpZXNnQGlldGYub3JnPjsgYW5pbWEtY2hhaXJzQGlldGYub3Jn OyBhbmltYUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBBbGlzc2EgQ29vcGVy J3MgQmxvY2sgb24NCj4gPj4gY2hhcnRlci1pZXRmLWFuaW1hLTAxLTA1OiAod2l0aCBCTE9DSyBh bmQgQ09NTUVOVCkNCj4gPj4NCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+PiBJ4oCZdmUgYmVlbiBk aXNjdXNzaW5nIHRoaXMgb24gbXkgd2Vla2x5IGNhbGwgd2l0aCB0aGUgT1BTIEFEcyBmb3IgdGhl DQo+ID4+IGxhc3QgY291cGxlIG9mIHdlZWtzIGFuZCBiYXNlZCBvbiB0aGUgY2FsbCB0aGF0IHdl IGhhZCBlYXJsaWVyIHRvZGF5DQo+ID4+IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBub3cgd291 bGQgYmUgYSBnb29kIHRpbWUgdG8gcmUtcmV2aWV3Lg0KPiA+Pg0KPiA+PiBSZWdhcmRpbmcgdGhp cyB0ZXh0OiAiTmV3IHdvcmsgaXRlbXMgd2lsbCBiZSBhZG9wdGVkIGJ5IHRoZSBXRyBvbmx5DQo+ ID4+IGlmIHRoZWlyIGNvbnRyaWJ1dG9ycyB0YXJnZXQgdGhlbSB0byBlbnRlciBXRyBsYXN0IGNh bGwgd2l0aGluIGENCj4gPj4gbnVtYmVyIG9mIElFVEYgbWVldGluZyBjeWNsZXMgYWdyZWVkIGJ5 IHRoZSBBRC7igJ0NCj4gPj4NCj4gPj4gSSBzdGlsbCBkb27igJl0IGdldCB0aGlzLiBJdCBpcyBh IHZlcnkgY29tbW9uIGNhc2UgdGhhdCBjb250cmlidXRvcnMNCj4gPj4gdGhpbmsgdGhlaXIgZHJh ZnRzIGFyZSBnb2luZyB0byBnZXQgdGhyb3VnaCB0byBXR0xDIGluIFggY3ljbGVzLCBhbmQNCj4g Pj4gdGhlbiB0aGV5IGVuZCB1cCB0YWtpbmcgMlggb3IgMTBYIGJlY2F1c2Ugc29tZSBuZXcgcGVy c29uIHdhbmRlcnMNCj4gPj4gaW50byB0aGUgV0cgb3Igc29tZSBvdGhlciB3b3JrIHN0YXJ0cyB1 cCBpbiBhbm90aGVyIFdHIHRoYXQgaGFzIGFuDQo+ID4+IGludGVyc2VjdGlvbiB3aXRoIHRoZSB3 b3JrIG9yIHNvbWVvbmUgY2hhbmdlcyBqb2JzIG9yIGFueSBtYW5uZXIgb2YNCj4gPj4gb3RoZXIg dGhpbmdzLiBUaGUgV0cgbmVlZHMgbWlsZXN0b25lcyB3aXRoIGRhdGVzLCBwcmVmZXJhYmx5IGF0 IHRoZSBwb2ludCBvZg0KPiBhcHByb3ZpbmcgdGhlIHJlLWNoYXJ0ZXIuDQo+ID4+IFRob3NlIG1p Z2h0IGJlIG1pc3NlZCB0b28sIGJ1dCB0aGVyZSBtaWdodCBhcyB3ZWxsIG5vdCBiZSB0d28gc2V0 cyBvZg0KPiA+PiBtYXJrZXJzIGxhaWQgZG93biB0aGF0IGFyZSBwb3RlbnRpYWxseSBnb2luZyB0 byBiZSBtaXNzZWQgcmF0aGVyIHRoYW4gb25lIHNldC4NCj4gPg0KPiA+IEkgaGF2ZSBqdXN0IGRl bGV0ZWQgdGhlIHNlbnRlbmNlLiBJdCdzIHNvbWV0aGluZyB0aGUgY2hhaXJzIGNhbiBkbyBkdXJp bmcgdGhlDQo+IFdHIG1hbmFnZW1lbnQgcHJvY2Vzcy4gV2UgdHJpZWQgdG8gZ2l2ZSBkcmFmdCBv d25lcnMgc29tZSBwcmVzc3VyZSBub3QgdG8NCj4gYmUgdG9vIHNsb3cgYnkgYWRkaW5nIHRoZXNl IHRleHQuIEkgZG8gYWdyZWUgdGhpcyBzaG91bGQgbm90IGJlIHNvIHJpZ2lkIGFzIHRoZXNlDQo+ IHRleHQuIFNvLCBsZXQncyB0YWtlIGl0IG91dCBhbmQgdGhlIGNoYWlycyB3aWxsIG1vbml0b3Ig dGhlIHByb2dyZXNzIG9mIFdHIGRyYWZ0cw0KPiBjbG9zZWx5Lg0KPiANCj4gVGhhbmtzLg0KPiAN Cj4gPg0KPiA+PiBSZWdhcmRpbmcgdGhlIOKAnGluZGljYXRpdmUgc2NvcGUgb2YgcG9zc2libGUg d29yayBpdGVtc+KAnSDigJQgdGhpcw0KPiA+PiBkb2VzbuKAmXQgYWRkcmVzcyBteSBjb25jZXJu IGFib3V0IHRoZSBXR+KAmXMgc2NvcGUuIFRoaXMgY2hhcnRlciBpcyBpbg0KPiA+PiBjb250cmFz dCB0byB0aGUgY3VycmVudCBBTklNQSBjaGFydGVyLCB3aGljaCBzYXlzOiAiVGhlIGluaXRpYWwg c2V0DQo+ID4+IG9mIHdvcmsgaXRlbXMgaXMgbGltaXRlZCB0byB0aGUgYWJvdmUgbGlzdCB0byBz dGF5IGZvY3VzZWQgYW5kIGF2b2lkDQo+ID4+ICdib2lsaW5nIHRoZSBvY2VhbuKAmS7igJ0gSSBk b27igJl0IHNlZSB0aGUgcmF0aW9uYWxlIGZvciBub3QgY2FycnlpbmcgdGhhdA0KPiA+PiBmb3J3 YXJkIHRvIHRoZSBuZXh0IHNldCBvZiBzcGVjaWZpYyB3b3JrIGl0ZW1zIHdoZXJlIFdHIHBhcnRp Y2lwYW50cw0KPiA+PiBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcmVzdCBhbmQgaW50ZW50IHRvIGNh cnJ5IHRoZSB3b3JrIGZvcndhcmQuIElmDQo+ID4+IHRoYXQgaXMgdGhlIGxpc3Qgb2YgaW5pdGlh bCBtaWxlc3RvbmUgdG9waWNzIGxpc3RlZCwgdGhlbiBsaW1pdGluZyB0byB0aGF0IG1ha2VzDQo+ IHNlbnNlIHRvIG1lLg0KPiA+DQo+ID4gSSBoYXZlIGFkZGVkIGEgc3BlY2lmaWMgbGlzdCBvZiB3 b3JrIGl0ZW1zIGludG8gdGhlIGluaXRpYWwgbWlsZXN0b25lIGxpc3QuDQo+ID4NCj4gPiBPYnZp b3VzbHksIHRoaXMgaW5pdGlhbCBtaWxlc3RvbmUgbGlzdCBkb2VzIE5PVCBjb3ZlciBhbGwgdGhl IHRvcGljcw0KPiA+IHRoYXQgV0cgcGFydGljaXBhbnRzIGhhdmUgc2hvd2VkIGludGVyZXN0cyBh bmQgd2lsbGluZ25lc3MgdG8gd29yayBvbi4NCj4gPiBUaGUgcHVycG9zZSB0byBoYXZlIHRoaXMg ZGVzY3JpcHRpb24gb2YgImluZGljYXRpdmUgc2NvcGUgb2YgcG9zc2libGUNCj4gPiB3b3JrIGl0 ZW1z4oCdIGFyZSBhY3R1YWxseSB0d286IEEsIGxpbWl0IHRoZSBwb3RlbnRpYWwgd29yayBpdGVt cyBub3QgdG8NCj4gPiBiZSB0b28gd2lkZQ0KPiANCj4gSSB0aGluayBteSBkaXNjb25uZWN0IGhl cmUgaXMgdGhhdCB0aGUgbGlzdCBkb2VzbuKAmXQgYWN0dWFsbHkgbGltaXQgdGhlIFdH4oCZcyBz Y29wZQ0KPiBiZWNhdXNlIGl0IHVzZXMgdGhlIGxhbmd1YWdlIOKAnGluZGljYXRpdmUgc2NvcGUg b2YgcG9zc2libGUgd29yayBpdGVtc+KAnSBhbmQNCj4g4oCcaW5jbHVkaW5nIGJ1dCBub3QgbGlt aXRlZCB0by7igJ0gVGhlIGZpdmUgYXJlYXMgb2Ygd29yayBpbiB0aGlzIGxpc3Qgc2VlbSBicm9h ZCBhbmQNCj4gbGFyZ2UgZW5vdWdoIHRvIGtlZXAgdGhlIFdHIGJ1c3kgZm9yIHF1aXRlIHNvbWUg dGltZS4gRm9yIHRoZSBjaGFydGVyIHRvDQo+IGVmZmVjdGl2ZWx5IGxpbWl0IHRoZSBzY29wZSBJ IHRoaW5rIGl0IHdvdWxkIG5lZWQgdG8gc2F5IOKAnFRoZSBzY29wZSBvZiB3b3JrIGl0ZW1zDQo+ IGlzIGxpbWl0ZWQgdG864oCdIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQo+IA0KPiBUaGFua3Ms DQo+IEFsaXNzYQ0KPiANCj4gPiAsIG90aGVyd2lzZSwgcGVvcGxlIG1heSB0YWtlIGFueXRoaW5n IGhhcyB0aGUgd29yayAiYXV0b21hdGljIiB0byB0aGUgV0c7IEIsDQo+IHRvIGdpdmUgdGhlIGNo YWlycyBhIGxpdHRsZSBiaXQgZmxleGliaWxpdHkgdG8gYWRvcHQgbmV3IHdvcmtzIGJleW9uZCB0 aGUgaW5pdGlhbA0KPiBtaWxlc3RvbmUgbGlzdC4gV2UgdHJ5IHRvIGF2b2lkIHRoZSBwcm9ibGVt IHRoYXQgZXZlcnkgdGltZSBhIG5ldyBkcmFmdCBjb21lcyB1cCwNCj4gaXQgbWF5IGJlY29tZSBh IGNoYXJ0ZXIgcmV2aXNpb24sIHBhcnRpY3VsYXJseSwgZ2l2aW5nIHRoZSBjdXJyZW50IHJlLWNo YXJ0aW5nDQo+IHByb2Nlc3MgaGF2ZSB0YWtlbiB1cyBtYW55IG1vbnRocy4NCj4gPg0KPiA+IEJl c3QgcmVnYXJkcywNCj4gPg0KPiA+IFNoZW5nDQo+ID4NCj4gPj4gVGhhbmtzLA0KPiA+PiBBbGlz c2ENCj4gPj4NCj4gPj4+IE9uIEp1biAxMCwgMjAxOSwgYXQgOTowMiBQTSwgQnJpYW4gRSBDYXJw ZW50ZXINCj4gPj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pg0K PiA+Pj4gSGkgYWxsLA0KPiA+Pj4NCj4gPj4+IEkndmUgdGFrZW4gdGhlIGxpYmVydHkgb2YgcG9z dGluZyBhbiB1cGRhdGUgdG8gdGhlIGRyYWZ0IGNoYXJ0ZXIgYXQNCj4gPj4+IGh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL2FuaW1hL3dpa2kvUmVjaGFydGVyMjAxOS4gSSB0cmllZCB0bw0KPiA+ Pj4gcmVzcG9uZCB0byBhbGwgdGhlIElFU0cgY29tbWVudHMsIGFuZCBpbiBwYXJ0aWN1bGFyOg0K PiA+Pj4NCj4gPj4+IChhKSBJIGRlbGV0ZWQgSW50ZW50IGZyb20gdGhlIHN1bW1hcmlzZWQgcmVm ZXJlbmNlIG1vZGVsIGZyYW1ld29yaywNCj4gPj4+IHNpbmNlIHRoZSByZWZlcmVuY2UgbW9kZWwg ZG9lc24ndCB1c2VmdWxseSBkZWZpbmUgSW50ZW50Lg0KPiA+Pj4NCj4gPj4+IChiKSBJIHRyaWVk IHRvIG1ha2UgdGhlIHN0YXRlbWVudCBhYm91dCB3b3JrbG9hZCB0aHJvdHRsaW5nIG1vcmUNCj4g Pj4+IGltcGxlbWVudGFibGUuDQo+ID4+Pg0KPiA+Pj4gKGMpIEkgc3RpbGwgdGhpbmsgdGhhdCB0 aGUgbGF1bmRyeSBsaXN0IG9mICpwb3NzaWJsZSogd29yayBpdGVtcyBpcw0KPiA+Pj4gdXNlZnVs IChpdCBoZWxwcyB0byBkZWZpbmUgdGhlIHNjb3BlKSBidXQgSSd2ZSB0cmllZCBtYWtlIGl0IGNs ZWFyDQo+ID4+PiB0aGF0IGl0IGlzIG9ubHkgdGhlICJpbmRpY2F0aXZlIHNjb3BlIG9mIHBvc3Np YmxlIHdvcmsgaXRlbXMiLg0KPiA+Pj4gSXQgcmVhbGx5IGlzbid0IG1pc3Npb24gY3JlZXA7IGFs bCB0aGUgaXRlbXMgbWVudGlvbmVkIHJlbGF0ZQ0KPiA+Pj4gZGlyZWN0bHkgdG8gdGhlIEFOSSBh bmQgQUYgdG9waWNzLg0KPiA+Pj4NCj4gPj4+IChkKSBJIGludGVudGlvbmFsbHkgcmVtb3ZlZCB0 aGUgcmVmZXJlbmNlIHRvIG5vdCBjb3ZlcmluZyBtYWNoaW5lDQo+ID4+PiBsZWFybmluZyBhbmQg QUkuIEl0IGlzbid0IHN1Z2dlc3RlZCBhbnl3aGVyZSBpbiB0aGUgcmVmZXJlbmNlIG1vZGVsLA0K PiA+Pj4gc28gd2h5IGV2ZW4gbWVudGlvbiBpdD8NCj4gPj4+DQo+ID4+PiAoZSkgSSBmaXhlZCBu aXRzIGFuZCB0dW5lZCB0aGUgd29yZGluZyBpbiBzZXZlcmFsIHBsYWNlcy4NCj4gPj4+DQo+ID4+ PiBJIGhvcGUgdGhpcyBoZWxwcy4gV2UgcmVhbGx5IG5lZWQgYSBuZXcgY2hhcnRlciBiZWZvcmUg TW9udHJlYWwuDQo+ID4+PiBXRyBDaGFpcnMgYW5kIEFELCBvdmVyIHRvIHlvdS4uLg0KPiA+Pj4N Cj4gPj4+IFJlZ2FyZHMNCj4gPj4+ICBCcmlhbiBDYXJwZW50ZXINCj4gPj4+DQo+ID4+PiBPbiAw Mi1NYXktMTkgMDg6MzksIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+IEhpIEFsaXNz YSwNCj4gPj4+Pg0KPiA+Pj4+IE9uIDAyLU1heS0xOSAwODowNSwgQWxpc3NhIENvb3BlciB2aWEg RGF0YXRyYWNrZXIgd3JvdGU6DQo+ID4+Pj4gLi4uDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ PiAtLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+PiBCTE9DSzoNCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ Pj4+IC0tDQo+ID4+Pj4+IC0tDQo+ID4+Pj4+DQo+ID4+Pj4+ICgxKSAiQWNjZXB0YW5jZSBvZiB3 b3JrIGl0ZW1zIGJ5IHRoZSBXRyB3aWxsIGJlDQo+ID4+Pj4+IHNjaGVkdWxlZC90aHJvdHRsZWQg c28gdGhhdCBjb250cmlidXRvcnMgY2FuIHRhcmdldCB0aGVtIHRvIGVudGVyDQo+ID4+Pj4+IFdH IGxhc3QgY2FsbCBhZnRlciBub3QgbW9yZSB0aGFuIGEgbnVtYmVyIG9mIElFVEYgbWVldGluZyBj eWNsZXMgYWdyZWVkDQo+IGJ5IHRoZSBBRC4iDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgZG9uJ3QgdW5k ZXJzdGFuZCB0aGUgaW1wbGljYXRpb25zIG9mIHRoaXMuIFdoYXQgaGFwcGVucyBpZiB0aGUNCj4g Pj4+Pj4gYWRvcHRlZCB3b3JrIGl0ZW1zIGhhdmUgbm90IGVudGVyZWQgV0dMQyBhZnRlciB0aGUg YWdyZWVkIG51bWJlcg0KPiA+Pj4+PiBvZiBjeWNsZXM/IElmIHRoZSBhbnN3ZXIgaXMgYW55dGhp bmcgb3RoZXIgdGhhbiAidGhlIFdHIGFiYW5kb25zDQo+ID4+Pj4+IHRoZSB3b3JrLCIgSSBkb24n dCB1bmRlcnN0YW5kIGhvdyB0aGlzIGlzIGEgdGhyb3R0bGluZyBtZWNoYW5pc20uDQo+ID4+Pj4+ IEEgdGhyb3R0bGluZyBtZWNoYW5pc20gd291bGQgbmVlZCBhbiBleHBsaWNpdCBsaW1pdCBvbiB0 aGUgbnVtYmVyDQo+ID4+Pj4+IG9mDQo+ID4+IGFkb3B0ZWQgd29yayBpdGVtcyBhdCBhbnkgb25l IHRpbWUsIEkgdGhpbmsuDQo+ID4+Pj4NCj4gPj4+PiBJIGFncmVlIHRoYXQgdGhlIHRleHQgaXMg YSBiaXQgaWxsb2dpY2FsLiBJbiBhIHNlbnNlIGl0J3MNCj4gPj4+PiB1bm5lY2Vzc2FyeSwgYmVj YXVzZSBldmVyeSBXRyBzaG91bGQgYmUgbWF0Y2hpbmcgaXRzIHdvcmtsb2FkIHRvDQo+ID4+Pj4g aXRzIGNhcGFjaXR5LiBNYXliZSB0aGF0J3MgYWxsIHdlIHNob3VsZCBzYXksIHJhdGhlciB0aGFu IHRyeWluZyB0bw0KPiA+Pj4+IGRlc2NyaWJlIGENCj4gPj4gc2xpZ2h0bHkgdmFndWUgYWxnb3Jp dGhtPw0KPiA+Pj4+DQo+ID4+Pj4+ICgyKSBUaGUgcHJvcG9zZWQgd29yayBpdGVtcyBpcyBhIHZl cnkgbGFyZ2UgYW5kIHNvbWV3aGF0IHVuYm91bmRlZA0KPiA+Pj4+PiBsaXN0IG9mIGl0ZW1zLCB3 aGVyZWFzIHRoZSBwdXJwb3NlIG9mIHdyaXRpbmcgYSBjaGFydGVyIGlzIHRvDQo+ID4+Pj4+IHNj b3BlIHRoZSB3b3JrIG9mIHRoZSBXRyBhbmQgaG9wZWZ1bGx5IHNldCBvdXQgYSByZWFsaXN0aWMg d29yaw0KPiA+Pj4+PiBwbGFuIHRoYXQgd2lsbCBiZSBhY2NvbXBhbmllZCBieSBkZXBsb3ltZW50 LiBGb3IgYSBXRyB0aGF0IGhhcw0KPiA+Pj4+PiBwcm9kdWNlZCA1IGRvY3VtZW50cyBpbiB0aGUg bGFzdCA1IHllYXJzLCBJIHRoaW5rIHRoZSBjaGFydGVyDQo+ID4+Pj4+IG5lZWRzIHRvIG1vcmUg bmFycm93bHkgZm9jdXMgb24gdGhlIG1vc3QgaGlnaGx5IHByaW9yaXRpemVkIHdvcmsNCj4gPj4+ Pj4gaXRlbXMuIE9uY2UgdGhvc2UgYXJlIG5lYXJpbmcgY29tcGxldGlvbiwgaXQgc2VlbXMgYXMg dGhvdWdoDQo+ID4+Pj4+IGV2YWx1YXRpb24gb2Ygd2hhdCBpcyBuZWVkZWQgbmV4dCBiYXNlZCBv biBkZXBsb3ltZW50IGV4cGVyaWVuY2UNCj4gPj4+Pj4gd291bGQgdGhlbiBkaWN0YXRlIHRoZSBu ZXh0DQo+ID4+IHNldCBvZiBpdGVtcyBmb3IgYW5vdGhlciByZS1jaGFydGVyLg0KPiA+Pj4+DQo+ ID4+Pj4gSSB0aGluayB0aGUgcG9pbnQgaGVyZSBpcyB0aGF0IG5vdyB0aGF0IHRoZSByZWxhdGl2 ZWx5IHNtYWxsIG51bWJlcg0KPiA+Pj4+IG9mIGluZnJhc3RydWN0dXJlIGRvY3VtZW50cyBhcmUg YWxtb3N0IGZpbmlzaGVkLCB0aGUgbmV4dCBzdGFnZQ0KPiA+Pj4+IG9wZW5zIHVwIHRoZSBwb3Nz aWJpbGl0aWVzIGZvciBhIG11Y2ggd2lkZXIgcmFuZ2Ugb2Ygd29yayB0aGF0DQo+ID4+Pj4gYnVp bGRzIG9uIHRoZSBpbmZyYXN0cnVjdHVyZS4gVGhlIHByaW9yaXRpZXMgYXJlbid0IGV2ZW4gb2J2 aW91cy4NCj4gPj4+PiBTbyB0aGlzIGdvZXMgd2l0aCB0aGUgcHJldmlvdXMgcG9pbnQsIGFuZCB0 byBxdWl0ZSBzb21lIGV4dGVudCB0aGUNCj4gPj4+PiBjcml0ZXJpYSB3aWxsIGJlIHdoZXRoZXIg dGhlIFdHIGhhcyBjYXBhY2l0eSBtb3JlIHRoYW4gd2hpY2ggdG9waWMgaGFzDQo+IHByaW9yaXR5 Lg0KPiA+Pj4+DQo+ID4+Pj4gVGhhdCdzIHdoeSB0aGVyZSdzIGEgYnVja2V0IGxpc3Qgb2Ygd29y ayBpdGVtcyBhbmQgYSBzaG9ydCBsaXN0IG9mDQo+ID4+Pj4gaW1tZWRpYXRlIG1pbGVzdG9uZXMu DQo+ID4+Pj4NCj4gPj4+PiBXb3VsZCB0aGlzIGhlbHA/DQo+ID4+Pj4NCj4gPj4+PiBzL1Byb3Bv c2VkIHdvcmsgaXRlbXMgaW5jbHVkZS4uLi9Qb3NzaWJsZSB3b3JrIGl0ZW1zIGluY2x1ZGUuLi4v DQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+IC0t DQo+ID4+Pj4+IC0tDQo+ID4+Pj4+IENPTU1FTlQ6DQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ PiAtLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBJdCB3b3VsZCBiZSBnb29kIHRvIHNl ZSBtaWxlc3RvbmVzIHdpdGggZGF0ZXMgYmVmb3JlIHRoaXMgZ2V0cyBhcHByb3ZlZC4NCj4gPj4+ Pj4NCj4gPj4+Pj4gSSB0aGluayB0aGlzIGNoYXJ0ZXIgd291bGQgYmVuZWZpdCBmcm9tIGFuIEVu Z2xpc2ggZWRpdCBwYXNzDQo+ID4+Pj4+IGJlZm9yZSBnb2luZw0KPiA+PiBvdXQgZm9yIGV4dGVy bmFsIHJldmlldy4NCj4gPj4+Pg0KPiA+Pj4+IEknbGwgdm9sdW50ZWVyLCB3aGVuIHRoZSBvcGVu IGlzc3VlcyBoYXZlIGJlZW4gcmVzb2x2ZWQuDQo+ID4+Pj4NCj4gPj4+Pj4gV2hhdCBpcyAiY29t cG91bmRpbmcgZW52aXJvbm1lbnQiPw0KPiA+Pj4+DQo+ID4+Pj4gQW4gZXhjZWxsZW50IHF1ZXN0 aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gICBCcmlhbg0KPiA+Pj4+DQo+ID4NCg0K From nobody Tue Jul 9 20:41:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA221200D7; Tue, 9 Jul 2019 20:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1xBPnxaJyl4D; Tue, 9 Jul 2019 20:41:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA131200B7; Tue, 9 Jul 2019 20:41:33 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 90C6CDBFE68B2F6B56C9; Wed, 10 Jul 2019 04:41:30 +0100 (IST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 04:41:30 +0100 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 10 Jul 2019 04:41:30 +0100 Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 10 Jul 2019 04:41:29 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Wed, 10 Jul 2019 11:41:24 +0800 From: Sheng Jiang To: "Fries, Steffen" , "anima@ietf.org" CC: "anima-chairs@ietf.org" , Eliot Lear , "Brockhaus, Hendrik" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wJcBnJAAFbcHCA= Date: Wed, 10 Jul 2019 03:41:24 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999EE4D0@NKGEML515-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92999EE4D0NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 03:41:37 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92999EE4D0NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Steffen, Thanks for your email. Your application are noted. I believe we have suffic= ient time for this coming meeting. Sheng From: Fries, Steffen [mailto:steffen.fries@siemens.com] Sent: Monday, July 08, 2019 6:20 PM To: Sheng Jiang ; anima@ietf.org Cc: anima-chairs@ietf.org; Eliot Lear ; Brockhaus, Hendrik = Subject: RE: Call for agenda ANIMA @ IETF 105, Montreal Hi Sheng, I would like to ask for a timeslot on: Name of time slot: BRSKI-AE (BRSKI with support for asynchronous enrollment= ) Name of draft(s): draft-fries-anima-brski-async-enroll-01.txt Time requested: 10min Presenter name(s): Eliot Lear The draft covers the support of asynchronous enrollment for situations in w= hich there is no or only a temporary connection to the CA issuing the certi= ficates. The approach uses self contained objects to bind the initial pledg= e authentication using the IDevID credential to the certification request. In comparison to version 00 this version enhances the application use case = description as well as the technical approach. It also starts the mapping t= o existing enrollment protocols. Best regards Steffen From: Anima > On Beha= lf Of Sheng Jiang Sent: Mittwoch, 26. Juni 2019 11:59 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs' email. Please note that ema= il to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B92999EE4D0NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Steffen,

&n= bsp;

Thanks = for your email. Your application are noted. I believe we have sufficient ti= me for this coming meeting.

&n= bsp;

Sheng

&n= bsp;

From: Fries, Steffen [mailto:steffen.fries@siemens.= com]
Sent: Monday, July 08, 2019 6:20 PM
To: Sheng Jiang <jiangsheng@huawei.com>; anima@ietf.org
Cc: anima-chairs@ietf.org; Eliot Lear <lear@cisco.com>; Brockh= aus, Hendrik <hendrik.brockhaus@siemens.com>
Subject: RE: Call for agenda ANIMA @ IETF 105, Montreal

 

Hi Sheng,

 

I would like to ask for a timeslot on:=

 

Name of time slot: BRSKI-AE (BRSKI wit= h support for asynchronous enrollment)

Name of draft(s): draft-fries-anima-br= ski-async-enroll-01.txt

Time requested: 10min

Presenter name(s): Eliot Lear

 

The draft covers the support of asynch= ronous enrollment for situations in which there is no or only a temporary c= onnection to the CA issuing the certificates. The approach uses self contained objects to bind the initial pledge authen= tication using the IDevID credential to the certification request.

In comparison to version 00 this versi= on enhances the application use case description as well as the technical a= pproach. It also starts the mapping to existing enrollment protocols.

 

Best regards

Steffen

 

From: Anima <anima-bounces@ietf.org> On Behalf Of Sheng Jiang
Sent: Mittwoch, 26. Juni 2019 11:59
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

 

Hi, all anima,

 


We have been allocated two sessions =
of 2 + 1.5 hour for the ANIMA WG meeting for IETF-105 (Montreal) - Tues=
day Morning session I and Afternoon session I. We are now starting to colle=
ct agenda items for the sessions. Please send your request for agenda by Ju=
ly 11th, Thursday, to anima-chairs=
@ietf.org and both chairs’ email. Please note that email to a sin=
gle chair may cause single failure.


 


For this coming meeting, we would li=
ke have the 1.5 hour session for BRSHI and Voucher relevant topics and the =
2 hour session for the others. As normal, the priority among these non-char=
ter work items would be: these that have active discussion in mail list, th=
en these have submitted drafts, and topics without drafts.


 


As you may observed, so far, our re-=
charter progress still not in the procedure. Until we have the new charter =
in the place by the IETF 105 week, we still not be able to adopt any new wo=
rk.


 


Please send us (anima-chairs at ietf.org<https://ietf.org/>;) requests for time slot by J=
uly 11th, Thursday and include:


 


Name of time slot:=



Name of draft(s):<=
/pre>

Time requested:

Presenter name(s):=



 


More details about the IETF 105, Mon=
treal can be found at:


 


https://www.ietf.org/how/meetings/105/=



 


Again, presenters and draft authors =
please invoke active discussions in the ANIMA list. Mail list is a very goo=
d place to discuss and reach consensus on technical issues.


 


Best regards,

 


Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B92999EE4D0NKGEML515MBSchi_-- From nobody Wed Jul 10 03:25:19 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC2D120099; Wed, 10 Jul 2019 03:25:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156275431789.15280.4126747621934962290.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 03:25:17 -0700 Archived-At: Subject: [Anima] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ani?= =?utf-8?q?ma-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 10:25:18 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you (and so many friends in the authors' list!) for the work put into this document; it took a while to get to this stage ;-) The intersection with MUD is also a nice feature. I have a couple of DISCUSSes (probably easy to fix) and _several_ COMMENTs and some nits (after a couple of nits, I stopped marking them). I also stopped writing COMMENTs after section 5.3. Regards, -éric == DISCUSS == TLS is assumed to be used but I failed to find WHICH version of TLS MUST be used. The only reference in the reference section is version 1.2. Probably worth to refer to this version in the text as well and use version 1.3 of TLS. -- Section 2.3.1 -- Does the "serial number" need to be unique per vendor ? I guess so then I strongly suggest to use a different word than "serial number" (e.g. unique device ID) as a vendor can have multiple products in its portfolio, each having a different set of unique "serial numbers". -- Section 3.3 -- The example 1 does not include the mandatory (per YANG module) serial-number. It should also state that the cert is not included for saving space in this document. -- Section 4.1 -- There are TWO back-off mechanisms: one for the method and one for the proxy but no description on how those mechanisms interact together. -- Section 4.3 -- Probably a naive question about GRASP (that I do not know), but in the example there is "IPPROTO_TCP, 80" that seems to indicate the use of plain HTTP and no TLS at all. Is it an issue ? Is there a reason why IPv6 ULA are used rather than the documentation prefix ? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == -- Section 1 -- Please introduce the MASA acronym used after. -- Section 1.1 -- > the pledge requires realtime connectivity to the manufacturer > service Why this connection requires "realtime" ? Esp when reading in section 1.3.1 "The bootstrapping process can take minutes to complete" -- Section 1.2 -- Please use the RFC 8174 boilerplate. "160-bit SHA-1 hash" I will let the security AD to check whether SHA-1 is deemed sufficient for this purpose. - Section 1.5 -- Please explain/refer GRASP acronym. -- Section 2 -- I wonder what will happen when the device vendor stops maintaining the MASA on-line? -- Section 2.2 -- Out of curiosity, why this document uses the word "voucher" as opposed to "ticket" ? -- Section 3.4 -- I find a little weird that the included YANG module has a different authors list than the document itself. Please refer to RFC 8174. "RFC YYYY: Voucher Profile for Bootstrapping Protocols" does not seem correct in a YANG module reference. -- Section 5 -- The MASA URI synthesis explanation is a duplicate of a previous explanation. Unsure whether it helps the reader. ... -- Section 8.4 -- I am afraid that the DNS service names have a length of maximum 15 characters. But, IANA is of course the source of truth. -- Appendix A -- Using IPv6 LLA should be enough, I do not see the reason to describe a new protocol using legacy IPv4 addresses because IPV6 link-local addresses should work on any decent layer-2 network. == NITS == A lot of "ethernet" and "internet" while those words are usually capitalized as "Ethernet" or "Internet". -- Abstract -- Shouldn't the plural form used in "using manufacturer installed X.509 certificate" ? -- Section 1.5 -- s/Some of the options in this document is the result of requirements/Some of the options in this document are the result of requirements/ ? -- Section 2.3.2 -- Please use uppercase in the protocol acronyms in "that MUST be supported, including ldap, http and ftp" .... -- Section 5.1 -- "A Pledge that can connect to multiple registries concurrently, SHOULD do so." lower case for pledge and what is the purpose of the comma in this sentence? (ok I am not an English native speaker so I can be wrong) From nobody Wed Jul 10 04:34:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09112012B; Wed, 10 Jul 2019 04:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dQFxsz8-ICQr; Wed, 10 Jul 2019 04:33:52 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9DC12011F; Wed, 10 Jul 2019 04:33:51 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C884F54805E; Wed, 10 Jul 2019 13:33:45 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B686E440041; Wed, 10 Jul 2019 13:33:45 +0200 (CEST) Date: Wed, 10 Jul 2019 13:33:45 +0200 From: Toerless Eckert To: Alissa Cooper , ibagdona@gmail.com Cc: Sheng Jiang , Brian E Carpenter , IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Message-ID: <20190710113345.j5mlcyfqpi2cfhi4@faui48f.informatik.uni-erlangen.de> References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B92999EAE8E@NKGEML515-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:33:56 -0000 Thanks for the update, Sheng! Ignas: can you pls. upload wiki 2.0.9 charter to datatracker ? Alissa: Thanks for your comments. I hope that the latest 2.0.9 version on the wiki as proposed by Sheng resolves your block. If not, then it would be great if we could accelerate resolving them so that we could actually start working on charter 2 @ IETF105. I think we always intended for what you proposed to be true, e.g: that whats not listed in the target work areas would require AD approval to be chartered. I guess we never wrote that explicitly because we had some even more specific mentioning of explicit AD approval cases in earlier versions of the proposed charter and those sentence got argued away by reviewers as being too procedural and unnecessary for a charter. Cheers Toerless On Mon, Jul 08, 2019 at 09:23:01AM -0400, Alissa Cooper wrote: > Hi Sheng, > > > On Jul 3, 2019, at 10:39 AM, Sheng Jiang wrote: > > > > Hi, Alissa, > > > > Thanks for your kindly response. I have made a new version (2.0.8) according to your feedback. Explanation in lines below. > > > > Please see https://trac.ietf.org/trac/anima/wiki/Recharter2019 > > > >> -----Original Message----- > >> From: Alissa Cooper [mailto:alissa@cooperw.in] > >> Sent: Wednesday, July 3, 2019 5:13 AM > >> To: Brian E Carpenter > >> Cc: IESG ; anima-chairs@ietf.org; anima@ietf.org > >> Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with > >> BLOCK and COMMENT) > >> > >> Hi all, > >> > >> I???ve been discussing this on my weekly call with the OPS ADs for the last > >> couple of weeks and based on the call that we had earlier today my > >> understanding is that now would be a good time to re-review. > >> > >> Regarding this text: "New work items will be adopted by the WG only if their > >> contributors target them to enter WG last call within a number of IETF meeting > >> cycles agreed by the AD.??? > >> > >> I still don???t get this. It is a very common case that contributors think their > >> drafts are going to get through to WGLC in X cycles, and then they end up > >> taking 2X or 10X because some new person wanders into the WG or some > >> other work starts up in another WG that has an intersection with the work or > >> someone changes jobs or any manner of other things. The WG needs > >> milestones with dates, preferably at the point of approving the re-charter. > >> Those might be missed too, but there might as well not be two sets of markers > >> laid down that are potentially going to be missed rather than one set. > > > > I have just deleted the sentence. It's something the chairs can do during the WG management process. We tried to give draft owners some pressure not to be too slow by adding these text. I do agree this should not be so rigid as these text. So, let's take it out and the chairs will monitor the progress of WG drafts closely. > > Thanks. > > > > >> Regarding the ???indicative scope of possible work items??? ??? this doesn???t > >> address my concern about the WG???s scope. This charter is in contrast to the > >> current ANIMA charter, which says: "The initial set of work items is limited to > >> the above list to stay focused and avoid 'boiling the ocean???.??? I don???t see the > >> rationale for not carrying that forward to the next set of specific work items > >> where WG participants have demonstrated interest and intent to carry the > >> work forward. If that is the list of initial milestone topics listed, then limiting to > >> that makes sense to me. > > > > I have added a specific list of work items into the initial milestone list. > > > > Obviously, this initial milestone list does NOT cover all the topics that WG participants have showed interests and willingness to work on. The purpose to have this description of "indicative scope of possible work items??? are actually two: A, limit the potential work items not to be too wide > > I think my disconnect here is that the list doesn???t actually limit the WG???s scope because it uses the language ???indicative scope of possible work items??? and ???including but not limited to.??? The five areas of work in this list seem broad and large enough to keep the WG busy for quite some time. For the charter to effectively limit the scope I think it would need to say ???The scope of work items is limited to:??? or something like that. > > Thanks, > Alissa > > > , otherwise, people may take anything has the work "automatic" to the WG; B, to give the chairs a little bit flexibility to adopt new works beyond the initial milestone list. We try to avoid the problem that every time a new draft comes up, it may become a charter revision, particularly, giving the current re-charting process have taken us many months. > > > > Best regards, > > > > Sheng > > > >> Thanks, > >> Alissa > >> > >>> On Jun 10, 2019, at 9:02 PM, Brian E Carpenter > >> wrote: > >>> > >>> Hi all, > >>> > >>> I've taken the liberty of posting an update to the draft charter at > >>> https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried to > >>> respond to all the IESG comments, and in particular: > >>> > >>> (a) I deleted Intent from the summarised reference model framework, > >>> since the reference model doesn't usefully define Intent. > >>> > >>> (b) I tried to make the statement about workload throttling more > >>> implementable. > >>> > >>> (c) I still think that the laundry list of *possible* work items is > >>> useful (it helps to define the scope) but I've tried make it clear > >>> that it is only the "indicative scope of possible work items". > >>> It really isn't mission creep; all the items mentioned relate directly > >>> to the ANI and AF topics. > >>> > >>> (d) I intentionally removed the reference to not covering machine > >>> learning and AI. It isn't suggested anywhere in the reference model, > >>> so why even mention it? > >>> > >>> (e) I fixed nits and tuned the wording in several places. > >>> > >>> I hope this helps. We really need a new charter before Montreal. > >>> WG Chairs and AD, over to you... > >>> > >>> Regards > >>> Brian Carpenter > >>> > >>> On 02-May-19 08:39, Brian E Carpenter wrote: > >>>> Hi Alissa, > >>>> > >>>> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: > >>>> ... > >>>>> -------------------------------------------------------------------- > >>>>> -- > >>>>> BLOCK: > >>>>> -------------------------------------------------------------------- > >>>>> -- > >>>>> > >>>>> (1) "Acceptance of work items by the WG will be scheduled/throttled > >>>>> so that contributors can target them to enter WG last call after not > >>>>> more than a number of IETF meeting cycles agreed by the AD." > >>>>> > >>>>> I don't understand the implications of this. What happens if the > >>>>> adopted work items have not entered WGLC after the agreed number of > >>>>> cycles? If the answer is anything other than "the WG abandons the > >>>>> work," I don't understand how this is a throttling mechanism. A > >>>>> throttling mechanism would need an explicit limit on the number of > >> adopted work items at any one time, I think. > >>>> > >>>> I agree that the text is a bit illogical. In a sense it's > >>>> unnecessary, because every WG should be matching its workload to its > >>>> capacity. Maybe that's all we should say, rather than trying to describe a > >> slightly vague algorithm? > >>>> > >>>>> (2) The proposed work items is a very large and somewhat unbounded > >>>>> list of items, whereas the purpose of writing a charter is to scope > >>>>> the work of the WG and hopefully set out a realistic work plan that > >>>>> will be accompanied by deployment. For a WG that has produced 5 > >>>>> documents in the last 5 years, I think the charter needs to more > >>>>> narrowly focus on the most highly prioritized work items. Once those > >>>>> are nearing completion, it seems as though evaluation of what is > >>>>> needed next based on deployment experience would then dictate the next > >> set of items for another re-charter. > >>>> > >>>> I think the point here is that now that the relatively small number > >>>> of infrastructure documents are almost finished, the next stage opens > >>>> up the possibilities for a much wider range of work that builds on > >>>> the infrastructure. The priorities aren't even obvious. So this goes > >>>> with the previous point, and to quite some extent the criteria will > >>>> be whether the WG has capacity more than which topic has priority. > >>>> > >>>> That's why there's a bucket list of work items and a short list of > >>>> immediate milestones. > >>>> > >>>> Would this help? > >>>> > >>>> s/Proposed work items include.../Possible work items include.../ > >>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------- > >>>>> -- > >>>>> COMMENT: > >>>>> -------------------------------------------------------------------- > >>>>> -- > >>>>> > >>>>> It would be good to see milestones with dates before this gets approved. > >>>>> > >>>>> I think this charter would benefit from an English edit pass before going > >> out for external review. > >>>> > >>>> I'll volunteer, when the open issues have been resolved. > >>>> > >>>>> What is "compounding environment"? > >>>> > >>>> An excellent question. > >>>> > >>>> Brian > >>>> > > -- --- tte@cs.fau.de From nobody Wed Jul 10 04:46:53 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960C01200E7 for ; Wed, 10 Jul 2019 04:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DPna4tx7ZlXd for ; Wed, 10 Jul 2019 04:46:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35A120026 for ; Wed, 10 Jul 2019 04:46:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 334FC548282; Wed, 10 Jul 2019 13:46:41 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 22CBA440041; Wed, 10 Jul 2019 13:46:41 +0200 (CEST) Date: Wed, 10 Jul 2019 13:46:41 +0200 From: Toerless Eckert To: William Atwood Cc: anima@ietf.org Message-ID: <20190710114641.wkaj6mfkhkxgmdaf@faui48f.informatik.uni-erlangen.de> References: <7019ff25-e185-87c3-6a0a-bc53528856dd@concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7019ff25-e185-87c3-6a0a-bc53528856dd@concordia.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Draft Charter 2.0.8 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:46:52 -0000 Thanks, Bill Having looked through a range of other charters before writing the current text, my feeling was that mentioning of drafts in charter is quite uncommon, so we tried to minimize this. The one exception we made was for the reference model, because it really is something like our current thinking of the blueprint for the overall intended ANIMA technical scope (without implying which parts thereof should be on any specific charter). Cheers Toerless On Wed, Jul 03, 2019 at 02:35:32PM -0400, William Atwood wrote: > In view of the fact that the Reference Model is specified as > "draft-ietf-anima-reference-model already approved for publication", and > that the ACP and Vouchers are specified by their RFC numbers, and that > BRSKI and GRASP are just as important as building blocks, I suggest that > citations should be given for BRSKI and GRASP. > > Bill > -- > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email:william.atwood@concordia.ca > 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 10 07:03:49 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3641200A1 for ; Wed, 10 Jul 2019 07:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JBszmH7mXI-Y for ; Wed, 10 Jul 2019 07:03:43 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1312002F for ; Wed, 10 Jul 2019 07:03:42 -0700 (PDT) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.217] port 64164) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id x6AE3Xca026886; Wed, 10 Jul 2019 10:03:34 -0400 To: Toerless Eckert Cc: anima@ietf.org References: <7019ff25-e185-87c3-6a0a-bc53528856dd@concordia.ca> <20190710114641.wkaj6mfkhkxgmdaf@faui48f.informatik.uni-erlangen.de> From: William Atwood Openpgp: preference=signencrypt Autocrypt: addr=william.atwood@concordia.ca; prefer-encrypt=mutual; keydata= mQGiBEmjdrMRBADawl3I6QQW9RTYKHQk0tMhjbbgi7clCKZzmgTOOHKYDil9J68+xyTdXlBT ud5crBx2kYf334Uf5fOBNBh6Z/3kUr2qkvVHXAp+yox81wao8pBwQ5wcnhPmnGhpsapCMeBA 3deiCQfvd9AVygrNZOJvW526PIHiNvob2pDT4ef0iwCgroVoHugkt+84Ly3jL9lcFFmqW38D /2exybJrzefDFGHExaQinYRwIovHhdilirh3k6BcRaS6xWUbWsra+w0OSQWCt+Ooaj6Zmeio 13U5lybjD4M0Se7TI0AW6JJsHot3x69/2Uq2OWb1cddezafZ4+vlNybC5LZ+tynTVt2RB7lE Yy34W9kTWIHsaFOLUjDaZW+ScpKoA/9yXM3FY7hUTBEgP5+CUyX4zYsnxtmeurhVi4D3Ri1e TRQhE/WxaVsxxqJuFNx/rzOPwnekWa06cb4mKYHJ6HJ/q1hjSCOvhlSUgLwQ6XiqYW/dulfL ulq6d9w01gApWPNdaimLOnZi/Of52YO7RZroSNPBwC71hOxzQCzeHZLgaLQxSm9obiBXaWxs aWFtIEF0d29vZCA8d2lsbGlhbS5hdHdvb2RAY29uY29yZGlhLmNhPohjBBMRAgAjAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAlC5EYcCGQEACgkQV5o4IdDwBVhFdACePdBrMqD3jC9V 53DbmgWkIR5oHVAAn1HPsfaMXQsIyim9d2wpwQunGDcXuQINBEmjdrMQCACDziZLszCCtC0i 195vC7UlKnKEE7rLKP+tzpJuPb6EW27xBtJ2cr6RXZQ84rrHvgczmhaht7kUPyyAFVUG2pbK 9vOBPcurdimtz4cc5FJ6v2wi9NoNaxag8MY2WYYzH7Fs4Bh7ZK7B6pR/lYVNltu8vxT7MO4p k+jjDaKkYU4VlN9dWrwTapmBbYafdOHhxnvxYrr3TsLdpYbGiucDwLtWGgd7+jx9LUT9tStg RgSYpwULZbQWHjSGRAXHtOzsk01TcTUP+rzbqteQ+3n867848rnJxoOWdOF73TR32dif0osf DAr4EuHHSkRI8a7me8zcVVZGhjQsp6JGsnhKO0AfAAMFB/9Cym72Z7nNw4ewqhVAVPal+tQG zkyh1S8vTEo6GdOK7eapc1OaSK7YCAS6UmFVTgoAjRBUPA5L7aLorSUXwzjZ7X26Pn2ywlnI c8+7AlbeGnggEg1h95QQTly+xU3ZEiBF0LhhyAwpISqGiz7zq44w2pqAxnAiKNX2xZxjHdZ+ yDMxT86Yj/U7K6ITv4/GwygS7bMt9+wXYRzvr9gHr5jKMEsTeIJHi5UNWLYfpfmhyF6sZ3KT qHFVAZ6yu2xDuAEhnIWaOUC2+Z9XHLMvgSrxIleqkKJiWZbAc9C1F/iV+DeQ7rNPNg9pN2Kr imkVfjdMTCwORUeeGprBurp3wCy/iEkEGBECAAkFAkmjdrMCGwwACgkQV5o4IdDwBVgd9gCf YD8t+Q9rphTC4HpOX9lHYEIIko8An2V2hchJax+LOGzSQOXOj8OgK3g3 Organization: Concordia University, Montreal Message-ID: Date: Wed, 10 Jul 2019 10:03:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190710114641.wkaj6mfkhkxgmdaf@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2019-07-10 10:03:34 EDT Archived-At: Subject: Re: [Anima] Draft Charter 2.0.8 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 14:03:47 -0000 Toerless, Well, I guess that if a reader can find the Charter, they can find the documents page. :-) Thank you for the explanation. Bill On 2019-07-10 7:46 a.m., Toerless Eckert wrote: > Thanks, Bill > > Having looked through a range of other charters before writing the > current text, my feeling was that mentioning of drafts in charter is > quite uncommon, so we tried to minimize this. The one exception we made > was for the reference model, because it really is something like our > current thinking of the blueprint for the overall intended ANIMA technical > scope (without implying which parts thereof should be on any specific charter). > > Cheers > Toerless > > On Wed, Jul 03, 2019 at 02:35:32PM -0400, William Atwood wrote: >> In view of the fact that the Reference Model is specified as >> "draft-ietf-anima-reference-model already approved for publication", and >> that the ACP and Vouchers are specified by their RFC numbers, and that >> BRSKI and GRASP are just as important as building blocks, I suggest that >> citations should be given for BRSKI and GRASP. >> >> Bill >> -- >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Distinguished Professor Emeritus fax: +1 (514) 848-2830 >> Department of Computer Science >> and Software Engineering >> Concordia University EV 3.185 email:william.atwood@concordia.ca >> 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill >> Montreal, Quebec Canada H3G 1M8 >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Wed Jul 10 07:59:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689DC120372 for ; Wed, 10 Jul 2019 07:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8JVVNTIbfv39 for ; Wed, 10 Jul 2019 07:59:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DBF12038E for ; Wed, 10 Jul 2019 07:59:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 954E154805E; Wed, 10 Jul 2019 16:59:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 82C0D440041; Wed, 10 Jul 2019 16:59:07 +0200 (CEST) Date: Wed, 10 Jul 2019 16:59:07 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, lamps@ietf.org, Sean Turner , Ignas Bagdonas , max pritikin , Benjamin Kaduk Message-ID: <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> References: <6535.1560786935@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6535.1560786935@dooku.sandelman.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 14:59:42 -0000 Thanks, Michael, inline On Mon, Jun 17, 2019 at 11:55:35AM -0400, Michael Richardson wrote: > > I have posted the draft > https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ > > this morning. It attempts to address the errata posted by Sean Turner in > 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and > base64. You can see my other query to httpbis at: > https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 > > In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we > had a number of confusions about whether or things are base64 encoded, and if > they are always base64 encoded, why send the CTE header, and if BRSKI is > binary or base64 encoded! > > Given that RFC7030 is somewhat well deployed, acting on the errata that Sean > Turner noted is a bit difficult! (As a process thing, it's a problem that > his 2017 errata seems to have gone into /dev/null). > > I am posting the core of the proposal at the bottom of this email. > It tries to leverage the Postel doctrine in a way. > > Some questions/issues: > > 1) does this belong in secdispatch? > > 2) is this appropriate for LAMPS? No idea, but if those WGs don't want to pick up the work, then i would certainly be happy to have the argument with OPS AD to do it in ANIMA given how i see this as an important dependency for BRSKI. Even though i would obviously prefer a WG thats more an expert at this. But "this" seems to be completely security unrelated and only about HTTP and payload encoding issues, so i fear its just considered to be a pain in the neck by every working group ;-) > 3) independant submission seems wrong. Yes. I think this should be a small, fast standardized update to 7030 and any possibly existing standards using 7030. Your document is a great start IMHO. My main suggestions would be some better strucutre and some more explanations. For the structure, i would just like to see sections 4..6 grouped into one section like "RFC7030 changes and clarifications". For the explanations i would primarily like to see a bit more text discussing backward compatibility and relationship to the 7030 erratas. >From what i guess to understand: Erratas 4384 and 5108 seem not to introduce any backward compatibility issues with whats observed in the field. So your draft suggest to adopt them. Errata 5107 on the other hand seems to be asking to remove CTE header by default, but doesn't really say what to do with 7030 base64 payload. One could interpret it to send binary which would be backward incompatible, or one could interpret it as sending base64 by mutual agreement, but without explicitly writing this into a text its guesswork. So your drafts section 4 seems to be this refinement of 5107 to close this gap, but it doesn't refer/explain to 5107 and explain the difference. What seems to be incomplete in your draft is whether to send or not to sent CTE, it only says to ignore it upon receipt. So, whats the minimum requirement for fully backward compatibility on sending ? -> EST server could deduce whether client rquires CTE by looking at EST client request headers and not send CTE when client doesn't use it ? -> EST client MUST continue to send CTE ? (not quite sure). Of course, 7030bis could specify non-fully backward compatible option, which is never to use CTE, but it would be good to explain real good technical reasons instead of just pointing to standards for HTTP. To me, the strongest technical reason is that proliferation of EST(bis) would be helped if EST(bis) can be implemented as an app on non-EST dedicated HTTP servers, and i think that was the whole point of of how EST was designed, and that is only possible when EST(bis) does not expect non-standard HTTP behavior. > 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on > this, but I'm hesistant to add a normative reference here. > I have an idea of appropriate text that I will post on Tuesday. > Getting clarity here is really the most important thing for me. I would like to see avoiding to drag this issue into BRSKI text unless we have to. I would simply have a reference to this draft in BRSKI and one sentence about it near the first mentioning of 7030 in BRSKI. If BRSKI finishes RFC before this draft, it would later be part of the update list of this draft once it becomes RFC. If this draft finishes RFC before BRSKI, we can still qickly fix up the BRSKI examples (i guess its's mostly examples). Even if BRSKI review asks for the document to become a normative dependency, its still better to have these signaling details not clutter up the BRSKI text and that cluttered text be something thart needs to be copied into other 7030 extensions. To do this, IMHO, the draft text you proposed should accordingly be extended to establish extensible guidance when to use no-CTE/base64-DER-payload vs. binary payload for existing and future messages. > 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved > by creating a new end point. or it could be done with Accept: header. How is the csrattr problem different ? Your section 4 looks as if it should/could be handled the same as the CA related command/replies. If not, then please add text explaining the issue. > ps: it's ironic to me, this is perhaps something that could also be solved > by versioning the API in the URL. Wouldn't really help for a CTE legacy client connecting to a new server and choking on the absence of CTE from that server, right ? > For the other three methods, when the client is aware that this is an Which other three methods ? (this text seems to be a bit out of context...) > amended server then it SHOULD send the POST request in binary form > (DER-encoded), and omit the Content-Transfer-Encoding header. How > the client knows what kind of server it is dealing with is > communicating with is detailed in the next section. > > An amended server, when it receives a request that has no Content- > Transfer-Encoding header, or has a Content-Transfer-Encoding header > with the "binary" attribute, MUST respond in the same binary format. > > When an amended server receives a request in CTE-base64 form, then it > MAY respond in kind. It is reasonable for a server to be configured > to ignore or fail requests of this form, either via run-time > configuration, or via a compile-time option. A main reason to do > this is to avoid a permutation that requires testing in the future > when no legacy EST clients are expected to connect. I'd say we need to figure out which methods from 7030 or extensions need to continue using base64 DER payload (without CTE) because implementations exist that are relevant to be compatible with, all others use binary without CTE. And that text goes into the draft. I see no need to optimize base64 away given how i don't think that HTTP shouldn't really be the transport for bitrate sensitive communications. Aka: EST over COAP could of course all be binary. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 10 09:15:07 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F512003E; Wed, 10 Jul 2019 09:14:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 09:14:59 -0700 Archived-At: Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 16:14:59 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Eric’s Discuss position. Also a big thanks to Christian Huitema’s thorough SECDIR reviews and the associated improvements made as a result. I have a few more items: (1) Section 5.7. The format of a pledge status telemetry message seems underspecified. ** what are all of the fields (e.g., version appears in the example but no the text) ** what are the field formats (e.g., the format of the status field is inferred from the unlabeled example ** which fields are mandatory? ** Per the JSON snippet, is that normative is some way in describing the format? ** Also, how does a server receiving the telemetry messages behave when receiving unexpected JSON attributes? (2) Section 5.8.1. The format of the MASA audit log seems underspecified. Is the JSON snippet presented here normative to describe the MASA audit log response? (3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative? -- How should implementers take this language? -- Why are normative sections, like Section 11, discussing it? (4) Thank you for documenting “manufacturer control issues†in Sections 10.3 and 10.4. It helpfully lays justifies the current design approach. I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol†is exactly what is needed. My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business. The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modesâ€. Specifically: ** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4) ** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case). For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension. This is a substantial amount of work, and may be an area for future standardization workâ€. Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (5) Section 1.3.2. Cite the origin of the taxonomy which defines “class 2+†devices – likely RFC7228 (6) Section 1.5. Per “Upon successfully validating a voucher artiface, a status telemetry MUST be returned.â€, what is a “voucher artifaceâ€? is that just a “voucherâ€? (7) Section 2.6.1. What is a “Network Time Protocols†– specifically why is protocols plural? Is this something more than NTP? (8) Section 4.1. Per “The communication between the pledge is over IPv6 Link-Local addressesâ€, if that is the case, why does Figure 3 show IPv4 and Appendix A describes an IPv5 approach? (9) Section 5.1., Per “The pledge maintains a security paranoia concerning the provisional state …â€, what does it mean to “maintain a security paranoiaâ€? (10) Section 5.1. Per “A pledge that can not maintain as many connections as there are eligible proxies.â€, this is an unfinished sentence. What should the pledge do? (11) Section 5.2. created-on. The value to use in this field of this field is not described here. (12) Section 5.2. Per “All other fields MAY be omitted in the pledge voucher-requestâ€, should this be read as guidance that the fields mentioned above this text are mandatory (i.e., created-on, nonce, proximity-registrar-cert). If so, what value should pledges without clocks use? (13) Section 5.3. Per “If these validations fail the registrar SHOULD respond with an appropriate HTTP error codeâ€, a few questions: ** Is this text suggesting that silent failure? Given the text says SHOULD, validation could fail and the registrar would not share this failure? ** What specific codes should be used? (14) Section 5.4. Per “The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8 for [RFC6125] authentication of the MASA.â€, RFC6125 doesn’t have a Section 2.8. Please clarify how this connection is made. (15) Section 5.5. What is the relationship between the value of the created-on field passed by the pledge per Section 5.2, and described in Section 5.5 as being populated by the registrar. (16) Section 5.5. What is a “statistically unique identity†per the “idevid-issuer†field? (17) Section 5.7. Per the JSON snippet: ** It isn’t labeled as a figure or example; and isn’t referenced in the text. ** This isn’t valid JSON: no commas between items. What does the notation “/* TRUE=Success, FALSE=Failâ€â€ mean – opening with a /* and closing with a “? (18) Section 5.8.2. Per “Each time the Manufacturer Authorized Signing Authority (MASA) issues a voucher, it places it into the audit log for that device. The details are described in Section 5.8.â€, this reference to Section 5.8 on how the MASA logs doesn’t seem correct. Section 5.8 describes how a registrar asks a MASA about its logs. (19) Section 5.9.4. What happens if the pledge doesn’t re-negotiate an EST TLS session after been successful enrolled? (20) Section 5.9.4. In what way is a the SubjectKeyIdentifier included in the success telemetry message? (21) Section 6. What is “../voucherrequestâ€? (22) Section 7. Per “This section is considered non-normative: use suggested methods MUST be detailed in specific profiles of BRSKI†-- the clause after the colon doesn’t parse. What is the guidance relative to profiles? (23) Section 11.0. The caution about untrusted data and HTTP libraries seems warranted. Wouldn’t this also apply to the application code too? (24) Section 11.1. Per the list of examples where a MASA is unavailable or uncooperative, wouldn’t a manufacturing going out of business also be a concern? (25) Section D.1.4. Provide an openssl version and reference that generated this output (26) Per Christian Huitema’s Last Call SecDir Review (https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra-20-secdir-lc-huitema-2019-06-04/), please respond to the last two issues – random number generation and the missing assertion leaf. (27) Editorial Section 1. Duplicate Word. s/Section Section/Section/ Section 1. Editorial. /(or be discovered by)/(or are discovered by)/ Section 1.1. Typo. s/transfered/transferred/ Section 1.1. Typo. s/serveral/several/ Section 1.2. The term “drop ship†is initial stated with a space, but is later used with a hyphen in the definition. Consistency is recommended. Section 1.3.1. Typo. s/aquire/acquire/ Section 1.3.3. Typo. s/consistant/consistent/ Section 1.3.4. Typo. s/transfered/transferred Section 2.3.2. Typo. s/docucment/document/ Section 2.3.2. Typo. s/registrary/registrar/ Section 2.5.4. Typo. s/seperate/separate/ Section 2.6.1. Typo. s/certificiate/certificate/ Section 3.4. Missing letter. s/conn ection/connection/ Section 3.4. Typo. s/occurance/occurrence/ Section 4. Typo. s/refered/referred/ Section 4. Typo. s/occuring/occurring/ Section 5. Typo. s/boostrap/bootstrap/ Section 5.1. Typo. s/atttempts/attempts/ Section 5.1. Typo. s/making process/making progress/ Section 5.2. Typo. s/impementations/implementations/ Section 5.5. Typo. s/impementations/implementations/ Section 5.5. Typo. s/recieved/received/ Section 5.5.7. Typo. s/is exist/exists/ Section 5.6. Typo. s/approriate/appropriate/ Section 5.6. Duplicate word. s/section Section/Section/ Section 5.6. Typo. s/sufficent/sufficient/ Section 5.6.1. Typo. s/manufacter/manufacturer/ Section 5.8.1. Duplicate word. s/the the/the/ Section 5.8.2. Typo. s/dicussion/discussion/ Section 5.8.2. Typo. s/evens/events/ Section 5.8.2. Typo. s/anomoly/anomaly/ Section 5.9.2. Typo. s/boostrapping/bootstrapping/ Section 5.9.4. Typo. s/adminstrative/administrative/ Section 5.9.6. Typo. s/defintion/definition/ Section 7.2. Typo. s/innappropriate/inappropriate/ Section 9. Typo. s/signficant/significant/ Section 9. Typo. s/consistenting/consisting/ Section 9. Duplicate Word. s/like like/like/ Section 9. Editorial. The sentence “Such an operator also is …†does not parse without the parenthetical. Perhaps it should read like “Such an operator is also capable of performing bootstrapping of a device using a serial-console.†Section 9. Typo. s/signficiant/significant/ Section 9. Duplicate word. s/still still/still/ Section 10.2. Typo. s/targetted/targeted/ Section 10.2. Typo. s/comissioning/commissioning/ Section 10.2. Typo. s/constrast/contrast/ Section 10.2. Typo. s/redesigs/re-designs/ Section 10.2. Typo. s/seperate/separate/ Section 10.3. Typo. s/responsability/ responsibility/ Section 10.3. Duplicate Word. s/the the/the/ Section 10.3. Typo. s/occurrance/occurrence/ Section 10.4. Typo. s/informatin/information/ Section 10.5. Typo. s/gratutiously/gratuitously/ Section 10.5. Duplicate word. s/these these/these/ Section 10.5. Typo. s/facilitiates/facilitates/ Section 10.5. Typo. s/operatonal/operational/ Section 10.5. Typo. s/warantee/warrantee/ Section 10.5. Typo. s/requiments/requirements/ Section 11.0. Typo. s/truely/truly/ Section 11.2. Typo. s/Retreival/Retrieval/ Section 11.2. Typo. s/occurance/occurrence/ Section 11.4. Typo. s/Maintainance/Maintenance/ Section 11.4. Typo. s/environements/environments/ From nobody Wed Jul 10 12:26:45 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC99120143; Wed, 10 Jul 2019 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WCSfRilD7j85; Wed, 10 Jul 2019 12:26:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C584412006B; Wed, 10 Jul 2019 12:26:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 41C573818E; Wed, 10 Jul 2019 15:24:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0D224A8A; Wed, 10 Jul 2019 15:26:31 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3F=3DC3=3D89ric=5FVyncke=3F=3D?= cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156275431789.15280.4126747621934962290.idtracker@ietfa.amsl.com> References: <156275431789.15280.4126747621934962290.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ani?= =?utf-8?q?ma-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:26:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric, thank you for the comments. WG and other authors, please look for XXX as your point where I'd like your input. I will push a -23 on the 22nd when draft submissions open, unless you want = it faster. Here is a pointer to get a diff between -22 and what is now in github: https://tinyurl.com/y2ex324x I want to point to a thread that this document needs to Updates: RFC7030, as it is extending the /.well-known/est namespace. It would be great to have the IESG's agreement on this, or suggest an alternative. =C3=89ric Vyncke via Datatracker wrote: > =3D=3D DISCUSS =3D=3D > TLS is assumed to be used but I failed to find WHICH version of TLS > MUST be used. The only reference in the reference section is version > 1.2. Probably worth to refer to this version in the text as well and > use version 1.3 of TLS. First, in developing this protocol we thought a lot about some of the priva= cy enhancements that TLS 1.3 could provide us, particularly around keeping the identifying parts of the IDevID (present in the Certificate), and we thought about >=3D1.3, but we did not want to tie things up for vendors. We also considered strongly always having the JRC initiate the TLS, because the ClientCertificate is sent first in TLS, and the JRC has no real privacy needs. We did not do this, even though there were strong requirements from the 6tisch WG to give the JRC more control over enrollment order/bandwidth. We decided to sit on the fence about TLS versions because Getting a TLS version through an evaluation process and into a firmware for a BFR wasn't something we wanted to gate BRSKI upon. As such, we think we are happy with any version of TLS that the TLS WG recommends. We further recognize that Registrar's MAY have to be willing to talk to versions which are older than whatever is considered secure that year. A device that has been in a box in a warehouse won't have the latest patches, and it won't have the latest patches until it goes through an onboarding process. The alternative is a truck roll, a USB stick, and some gum. We reference RFC7030, and it's section 3.3.1 says TLS 1.1 (now considered old), but we didn't like that it even specified what is now an obsolete cipher suite. That's one reason we felt that we shouldn't overspecify: that's the TLS WG's job. It would be nice to be able to point to a STD XX for this. Would you like us the add something in section 5.1? > -- Section 2.3.1 -- > Does the "serial number" need to be unique per vendor ? I guess so th= en I > strongly suggest to use a different word than "serial number" > (e.g. unique device ID) as a vendor can have multiple products in its > portfolio, each having a different set of unique "serial numbers". We are leverging the serialNumber attribute from 802.1AR (and RFC5280). Since this is an attribute in a certificate's DN, it's uniqueness is defined by the issuer of the certificate. Different issuer public keys would have different serialNumber namespaces. Since the voucher-request is signed by the IDevID, that value is also within the IDevID issuer's namespace. A vendor that operates different signing authorities for different products could decide to keep it's serialNumbers unique across all products. I would certainly recommend that, but from a technical point of view, unnecessary. > -- Section 3.3 -- > The example 1 does not include the mandatory (per YANG module) > serial-number. > It should also state that the cert is not included for saving space in > this document. I have added serial-number to the example. > -- Section 4.1 -- > There are TWO back-off mechanisms: one for the method and one for the > proxy but > no description on how those mechanisms interact together. The first back-off is for the active methods of discovery. (Those methods are optional, GRASP M_FLOOD is the MTI) The second back-off is for attempts to connect to a specific proxy. I don't see an interaction or an issue. The timers are separate. Maybe you can explain your concern? If we see M_FLOOD messages from a new proxy, then we'd start (immediately) trying that new connection, even if there are TCP half-open connections to via proxies. > -- Section 4.3 -- > Probably a naive question about GRASP (that I do not know), but in the > example there is "IPPROTO_TCP, 80" that seems to indicate the use of > plain HTTP and no TLS at all. Is it an issue ? Yes, I agree that is confusing. It can be 443,, or actually any port that the registrar chooses. Are you okay with 8443 to emphasize that it is arbitrary? > Is there a reason why IPv6 ULA are used rather than the documentation > prefix ? yes, we assume that this communication runs over ANIMA's ANI ACP. The ACP is explicitely numbered in ULAs, and we felt that using a GUA (which the documentation prefix is), would confuse people, particularly security people, into thinking that parts of the protocol run over the open internet. If have considered that we ought to have a documentation ULA prefix, and we could allocate that out of the ULA-"C" space (fc00::/8). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > =3D=3D COMMENTS =3D=3D > -- Section 1 -- > Please introduce the MASA acronym used after. Done. > -- Section 1.1 -- >> the pledge requires realtime connectivity to the manufacturer >> service > Why this connection requires "realtime" ? Esp when reading in section > 1.3.1 "The bootstrapping process can take minutes to complete" realtime as opposed store and forward, via, for instance USB key or email over UUCP. > -- Section 1.2 -- > Please use the RFC 8174 boilerplate. > "160-bit SHA-1 hash" I will let the security AD to check whether SHA-= 1 is > deemed sufficient for this purpose. RFC5280 uses it, and we don't have a common replacement for this (or even a good name for it). It is only used in the audit log to identify previous owners. We could easily add a second hash to the audit log. > - Section 1.5 -- > Please explain/refer GRASP acronym. reference added. > -- Section 2 -- > I wonder what will happen when the device vendor stops maintaining the > MASA on-line? please see flamewar^Wsec-dir review thread last fall :-) https://mailarchive.ietf.org/arch/msg/anima/XCS6JpwQSm3naOivwCYaO0AAsVs We added most of section 10 on this. In particular section 10.5 suggests that a manufacturer could permit the MA= SA anchors to be replaced and/or augmented. This divorces the device entirely From=20the manufacturer. An operator that goes this way probably should ha= ve source code: but that's no longer unreasonable for many platforms that provide virtualized services. > -- Section 2.2 -- > Out of curiosity, why this document uses the word "voucher" as oppose= d to > "ticket" ? Not sure, but I'd have argued against ticket because BRSKI/RFC8366 vouchers are significantly less functional than Kerberos tickets. > -- Section 3.4 -- > I find a little weird that the included YANG module has a different > authors list than the document itself. A good point. Steinthor changed jobs before we got fully into the YANG modelling. Kent did most of heavy YANG lifting, so we put him first, but I've sorted the rest alphabetically. > Please refer to RFC 8174. > "RFC YYYY: Voucher Profile for Bootstrapping Protocols" does not seem > correct in a YANG module reference. Fixed. > -- Section 5 -- > The MASA URI synthesis explanation is a duplicate of a previous > explanation. > Unsure whether it helps the reader. We included it in both section 5 and section 2.3.2, because in interop testing, we noticed that implementors of Registrar's often do *not* read the part about MASA operations, and VV, the IDevID certificate authority programmer is unlikely to understand section 5. > -- Section 8.4 -- > I am afraid that the DNS service names have a length of maximum 15 > characters. > But, IANA is of course the source of truth. XXX We have heard from IANA, and they did not complain as yet. > -- Appendix A -- > Using IPv6 LLA should be enough, I do not see the reason to describe a > new protocol using legacy IPv4 addresses because IPV6 link-local > addresses should > work on any decent layer-2 network. XXX: I personally have no objection to ripping out that legacy 1980s crap :-) I was happy to relegate it to a non-normative appendix. I'm gonna let the other authors and WG argue this point. > =3D=3D NITS =3D=3D > A lot of "ethernet" and "internet" while those words are usually > capitalized as > "Ethernet" or "Internet". okay, fixed. > -- Abstract -- > Shouldn't the plural form used in "using manufacturer installed X.509 > certificate" ? okay > -- Section 1.5 -- > s/Some of the options in this document is the result of > requirements/Some of > the options in this document are the result of requirements/ ? agreed. > -- Section 2.3.2 -- > Please use uppercase in the protocol acronyms in "that MUST be suppor= ted, > including ldap, http and ftp" okay. > .... > -- Section 5.1 -- > "A Pledge that can connect to multiple registries concurrently, SHOULD > do so." > lower case for pledge and what is the purpose of the comma in this > sentence? we had a mania at some point that argued that Pledge was a proper noun. We recovered from it. I think that comma belongs; maybe it SHOULD be a semi-colon. I'm happy to let the copy-editor argue it. I think that it seperates out a qualifying noun phrase. > (ok I am not an English native speaker so I can be wrong) ps: here is a video of the protocol from another non-native English speaker: https://vimeo.com/305041755 =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mO+YACgkQgItw+93Q 3WXn4wf9HOYYPihJmB7968/wBxky4e5urOGL3cEP4TK4mPcrNOAPR1Ks/v8tLrlG 3cMgS+7CxpmFCQ4dNhSFMsLTW/NitV2nr3sD/yiXHzUCv7ZfTZyMpxJjXcTe6uG3 23xtNHE7MhTwhNDjVBl0ycB0FajeYUf8+IePKtZyexbRbQT+ftwOj2dzbdxUGLrz itVhAyRNfr9N26NE+7iWPTMtdKfQY25N2nsGhaqEowC5a9kPBCcs3tCTPMYwG/Rc aIlLQIXS8hKyRUVvDGZ5xFdQtBHS5EYmRNQdpyyGPluVFgx1fo+JixMfKdF5xr4a uloo9AGD0lhzLAafefPNsL+kunzkoA== =kKms -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 13:42:33 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D495120147; Wed, 10 Jul 2019 13:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 13:42:30 -0700 Archived-At: Subject: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:42:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I apologize if I'm misunderstanding how this works, but I didn't see much discussion in the document about the implications of the manufacturer going out of business. Specifically, it seems like if a device ships with BRSKI as its only available mechanism for bootstrapping and the manufacturer goes out of business before the device is enrolled, the ability for the device to function securely on the network may be significantly impaired if not impossible. It seems like this document needs to make clear to manufacturers that a fallback manual enrollment mechanism of some sort needs to be implemented along with BRSKI in order to avoid this situation. = Section 1.3.1 = "But this solution is not exclusive to large equipment: it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user." I don't quite understand how this squares with the scope limitation described in Section 1 and Section 9. If the whole network is professionally managed by the ISP, what part would be the "hostile environment"? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this document would benefit from two concise lists, with notes about which items in each list are defined in this document and which ones are not defined: (1) what is operationally required of a manufacturer to support BRSKI, and (2) what is operationally required of a domain owner to support BRSKI. = Section 2.3.1 = What precisely is meant by "TPM identification"? Could a citation be provided? = Section 10.1 = "The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain." What does this mean? That the domain can expect the manufacturer not to trust the domainID because it hasn't been authenticated? = Section 10.2 = "The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer: that an enterprise/ISP purchases routing products is hardly worth mentioning. Deviations would, however, be notable." What does the last sentence mean? From nobody Wed Jul 10 13:45:15 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF42120381; Wed, 10 Jul 2019 13:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=y0HVZG/Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aVoM+iBV 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 QQ6Zt4xwuj0f; Wed, 10 Jul 2019 13:45:03 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E9212037B; Wed, 10 Jul 2019 13:45:00 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3E3BE43B; Wed, 10 Jul 2019 16:44:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 10 Jul 2019 16:44:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=C 30JX6EtYVV4s0tVncwm984gsanhRGCXfRBgLKvNAxY=; b=y0HVZG/YkaEiu4KQ9 FacYpwY+y3MYhJr3G5jY7nnCYKxXcc2jSEckFeUsPCxzrLPXbTY0tKpqx31k1Q4L SS5VoA9XU8OOqwCDxOxMMxksLLvc5zMux5dk62xPfnPpiNZXPY99F8V0aPfiJY9x z2SXKUpTj6oilI2YAyVRrQaDfBe88zU4BYavIhr6gxwZMbSVSSC9ycyE9Ouhd0K8 PmAZG45ytWxDcR2cN0WUnKv98lENr3vDEyxOIi2eIX8QBuhvMI+h0PoZ1YfXdbjf 9cyve2+dat6LGfXVO02cvkMrpXnrJfn7i2nNexD4TkolRqh/xnCDobBWKgWUCdIX 0jW6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=C30JX6EtYVV4s0tVncwm984gsanhRGCXfRBgLKvNA xY=; b=aVoM+iBV7c3XD6tZUwECyCykBbhzYmX0BSoPV50BhLkVmz9M2Uia/GW8G 6FlClPMTRXsPdKByEEiL7GMbW7OghCiE3CkwFfCG7q1JCXe+/HVYF0KnEWx9dm1F +J0HxFa1cS8Q5KDeBDj33sDI0J46Y8wGadPYnoD18rU6TcDDCigf4Z/hb3DTPF0v ptfDG0H1xq7i4xRqwL5FCf+GIZwR7Uo3rKiATGmFc6KlbZNc4vhnyetbL256Ly1j 7icnuS4lG3nTu0AEZv5l7TQy86DEL9Gm7axcgVeoJE+5KP4GZ4fDSDsVfZ/kpAfZ m3o7np+9MRU/Purx6HTsIAoeSGvPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeeigdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrledunecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id DB881380087; Wed, 10 Jul 2019 16:44:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153874289877.989.15433226866680411112@ietfa.amsl.com> Date: Wed, 10 Jul 2019 16:44:57 -0400 Cc: gen-art@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <791CADFA-EB89-47AE-A808-FEA9D3B93A00@cooperw.in> References: <153874289877.989.15433226866680411112@ietfa.amsl.com> To: Jari Arkko X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] [Gen-art] Genart last call review of draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:45:13 -0000 Jari, thanks for your review. I reviewed the issues list on Github and = it appears that the authors provided responses to all of your points, = addressing many of them with text updates. Authors, thanks for that. I = entered a DISCUSS ballot with just two outstanding comments. Alissa > On Oct 5, 2018, at 8:34 AM, Jari Arkko wrote: >=20 > Reviewer: Jari Arkko > Review result: Not Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-anima-bootstrapping-keyinfra-?? > Reviewer: Jari Arkko > Review Date: 2018-09-27 > IETF LC End Date: 2018-10-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > I have reviewed this document. My intent was to complete this review = by the > original Gen-ART and IETF last call deadline on October 2. = Unfortunately, > it took longer to read the document than expected, for which I = apologize. > Hopefully these comments are still useful. >=20 > I have some overall comments and then a number of more detailed = technical > and editorial comments. >=20 > First up, I agree with Christian Huitema's stellar review that was > posted earlier on the IETF list. He brought out many of the most > relevant questions about this specification. >=20 > I won't repeat those questions, but I'll observe that I *do* think it > is useful to build enrollment and imprinting protocols, for various > situations. It is beneficial for there to be standards in this space, > and for those standards to support use cases that fit me and others > that fit other people's goals. I do agree with Christian and others > that one has to be careful about doing that though, and be careful > about, for instance, avoid putting any party in a more controlling > role than others purely due to how the technology is constructed. >=20 > I did encounter a number of question marks and have several > suggestions throughout the document. It also wasn't an easy read, > particularly from the point of view of understanding what its > implications are. >=20 > My first bigger comment is that I believe the security and privacy > considerations section should have provided an actual in-depth > analysis of the characteristics offered by the protocol, perhaps under > several different situations, as the protocol can be operated in > different modes. >=20 > My second comment is that the protocol as defined is quite focused on > manufacturer-controlled situations. As Christian mentioned, there is > some discussion of other situations in the document (Section 6.4), but > not much, and there's little information on what happens if one tries > to use the protocol in this way. It would seem that a better support > for getting a voucher or vouchers when the device is new and the > manufacturer still around would alleviate some of the concerns that > were raised in the IETF list discussion. There's little information > about the security implications, little explanation of the various > lifetimes and when infinite lifetimes are OK and when not, etc. All > of those details would have been useful. But for now, it is difficult > to even evaluate those aspects, because I don't know if I can use > the protocol for in a more owner-oriented fashion. And if I can't, > is that because of a fundamental limit or because we chose to design > the protocol that way?=20 >=20 > More detailed technical comments: >=20 > Section 1: >=20 >> It uses a TLS connection and an PKIX (X.509v3) >> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer >> points 1 and 2. It uses a new artifact called a "voucher" that the >> registrar receives from a "Manufacturer Authorized Signing Authority" >> and passes to the pledge to answer points 3 and 2. >=20 > What is used to answer point 4? >=20 > Section 1.3.3: >=20 >> This document presumes that network access control has either already >> occurred, is not required, or is integrated by the proxy and >> registrar in such a way that the device itself does not need to be >> aware of the details. >=20 > I understand why this limitation is specified, but this does = considerably > reduce the number of cases where BRSKI can be applied. >=20 > Section 2.1: >=20 >> A unique nonce can be >> included ensuring that any responses can be associated with this >> particular bootstrapping attempt. >=20 > It seems odd to have such a fundamental request-response matching > be optional. Also, are these the same nonces as were described early > for one-time usage limits, or different? >=20 > Section 2.2: >=20 >> Vouchers provide a signed but non-encrypted communication channel >> among the pledge, the MASA, and the registrar. The registrar >> maintains control over the transport and policy decisions allowing >> the local security policy of the domain network to be enforced. >=20 > Is this a potential privacy vulnerability, as there are serial numbers > and possibly some other information in the voucher? (One could have, > for instance, exposed a hash of the relevant information during the > process onlu reveal the actual data once the encrypted channel is set > up to avoid this.) >=20 > Section 2.3: >=20 >> 4. (Optionally) communicating the MUD URL (see Appendix C. >=20 > There's plenty of potentially useful information that could be > communicated. The linkage to MUDs seems a bit arbitrary. Could > this perhaps be generalized? >=20 > Section 2.4: >=20 >> P---Voucher Request (include nonce)------>| | >=20 > Is this nonce the one inside the voucher or something different? >=20 > Section 3.1: >=20 >> grouping voucher-request-grouping >> +---- voucher >> +---- created-on? yang:date-and-time >> +---- expires-on? yang:date-and-time >> +---- assertion enumeration >> +---- serial-number string >=20 > I'm not sure it is necessary to base everything on a serial number. >=20 > Section 3.2: >=20 >> "proximity-registrar-cert": "base64encodedvalue=3D=3D" >=20 > I do not understand the notation that you are using here, nor did my > grep for the above string find anything from the RFC directory other > than in RFC 8366. Is "base64encodedvalue=3D=3D" a value that you are = using > as an example, or some special format that signifies something else? >=20 > Section 4: >=20 >> A proxy MAY assume TLS framing for auditing purposes, but MUST NOT >> assume any TLS version. >=20 > Is this specification sufficient to understand what this means > from a actual behaviour point of view? Must pass all bytes unchanged? >=20 > Section 4: >=20 >> In the ANI, the Autonomic Control Plane (ACP) secured instance of >> GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI >> registrar ACP addresses and ports by ANI proxies. The TCP leg of the >> proxy connection between ANI proxy and ANI registrar therefore also >> runs across the ACP. >=20 > MUST seems a strong keyword to use here. Perhaps some systems would > like to use another mechanism, but this MUST prohibits any such > changes. MUST support maybe... >=20 > Also, a bit later in Section 4.1 it says "The pledge MAY listen > concurrently for other sources of information" which would seem to > contradict the MUST. >=20 > Section 4.1: >=20 >> The result of discovery is a logical communication with a registrar, >> through a proxy. The proxy is transparent to the pledge but is >> always assumed to exist. >=20 > Is it really a requirement that it must exist? I could imagine > small networks where the registrar is on the network... >=20 > Section 4.1: >=20 >> A new temporary >> address SHOULD be allocated whenever the discovery process is >> forced to restart due to failures.=20 >=20 > Why is this necessary? It seems to set a pretty high requirement > on the integration of the IP stack and the brski functionality. > Presumably RFC 4941 is used by many applications and there > should be support in the general facility for sufficiently > frequent change of addresses. >=20 > Section 5: >=20 >> o The pledge either attempts concurrent connections, or it times out >> quickly and tries connections in series. >=20 > Concurrent connections to where? You mean multiple proxies? Be more > specific. >=20 > Section 5.2: >=20 >> nonce: The pledge voucher-request MUST contain a cryptographically >> strong random or pseudo-random number nonce. Doing so ensures >> Section 2.6.1 functionality. The nonce MUST NOT be reused for >> multiple bootstrapping attempts. >=20 > But elsewhere in the document you talk about the nonceless case, so > how can the nonce actually be mandatory? Or are there multiple nonces? > The document is unclear on this. >=20 > Section 5.4: >=20 >> The registrar SHOULD verify that the serial number >> field it parsed matches the serial number field the pledge >> provided in its voucher-request. >=20 > It is surprising that this is only a SHOULD. The pledge will > be made for a wrong device and/or there is an attack somewhere > if the two values don't match. >=20 > Section 5.4.7: >=20 >> It MAY perform a simple >> consistency check: If the registrar voucher-request contains a nonce >> and the prior-signed-voucher-request exists then the nonce in both >> MUST be consistent. >=20 > The formulation is odd, because you are specifying something optional > (MAY) which then has a MUST statement but that statement relates > to how things are supposed to be, not what the implementations should > do. >=20 > And again, I think these consistency checks should be mandatory. >=20 > Section 5.5: >=20 >> expires-on: This is set for nonceless vouchers. The MASA ensures >> the voucher lifetime is consistent with any revocation or pinned- >> domain-cert consistency checks the pledge might perform. See >> section Section 2.6.1. There are three times to consider: (a) a >> configured voucher lifetime in the MASA, (b) the expiry time for >> the registrar's certificate, (c) any certificate revocation >> information (CRL) lifetime. The expires-on field SHOULD be before >> the earliest of these three values. Typically (b) will be some >> significant time in the future, but (c) will typically be short >> (on the order of a week or less). The RECOMMENDED period for (a) >> is on the order of 20 minutes, so it will typically determine the >> lifespan of the resulting voucher. >=20 > There are several issues here, the lifetimes of the imprinting with > the owner/registrar vs. the lifetimes of the imprinting process > artifacts. Please clarify. I *think* you are talking about the > process expery times above, not about the expiry of the imprinting. > And certainly I'd hope 20min is not the duration of the imprinting, > but rather it needs to be infinite in most cases. >=20 > Section 5.5.2: >=20 >> The pinned-domain-cert MAY be installed as an trust anchor for future >> operations. >=20 > Could this be used for future imprinting, or only for other things? > Please clarify. >=20 > Section 5.7.1: >=20 >> 5.7.1. MASA audit log response >=20 > I found this section not providing enough details to tell what > the MASA should return. Everything? Only log entries concerning > the device in question? Log entries for the same domain as in > the indicated voucher request? >=20 > Section 5.7.2: >=20 >> A "proximity" assertion >> assures the registrar that the pledge was truly communicating with >> the prior domain and thus provides assurance that the prior domain >> really has deployed the pledge. >=20 > I don't think I understand the promixity assurances. Obviously, the > pledge and the owner's domain are in some kind of communication, > but not sure how that proves proximity, given that requests from > a pledge could easily be tunneled from somewhere else. >=20 > Section 6.2: >=20 >> 2. The pledge MAY support "trust on first use" for physical >> interfaces such as a local console port or physical user >> interface but MUST NOT support "trust on first use" on network >> interfaces. This is because "trust on first use" permanently >> degrades the security for all use cases. >>=20 >> 3. The pledge MAY have an operational mode where it skips voucher >> validation one time. For example if a physical button is >> depressed during the bootstrapping operation. This can be useful >> if the manufacturer service is unavailable. This behavior SHOULD >> be available via local configuration or physical presence methods >> (such as use of a serial/craft console) to ensure new entities >> can always be deployed even when autonomic methods fail. This >> allows for unsecured imprint. >=20 > I think #2 is actually too conservative; with a "TOFU" button one > would reasonably be able to pair devices to a local, previously > untrusted registrar. And #3 is I suppose something along those lines, > but defined quite imprecisely. One should verify the exchanges and > signatures and go through the whole process, but NOT require signature > from the trusted MASA. >=20 > Section 6.4: >=20 >> 6.4. MASA security reductions >> ... >> 1. Not enforcing that a nonce is in the voucher. This results in >> distribution of a voucher that never expires and in effect makes >> the Domain an always trusted entity to the pledge during any >> subsequent bootstrapping attempts. >=20 > Depending on your viewpoint this may be a security reduction or > increase. It is only a reduction if you are the manufacturer. Owners > and users might wish to protect themselves against the manufacturer, > however, in which case permanent vouchers are a feature, not a bug. >=20 > Section 8: >=20 >> 8. Privacy Considerations >=20 > This does not discuss the role of serial numbers and other > identifying information. >=20 > Section 9: >=20 >> 9. Security Considerations >=20 > I expected to find a section that would go through the protocol and > explain the security properties that it has, along with some > discussion of residual vulnerabilities. What I found was a discussion > of a handful of specific issues, such as the impacts of trusting the > manufacturers, or why the nonce design is the way it is in the > protocol. >=20 > I'd find it useful to have, say, a discussion for each major > mode of the protocol and what security properties it provides > and does not provide. >=20 > Nits/editorial comments:=20 >=20 >> BRSKI provides a solution for secure zero-touch (automated) bootstrap >> of virgin (untouched) devices that are called pledges in this >=20 > Maybe s/virgin (untouched)/new (unconfigured)/ >=20 >> Services that benefit from this: >> o Device management. >> o Routing authentication. >> o Service discovery. >=20 > Are these examples? If so, say so? Otherwise, please specify why these = services > and not others are suitable for BRSKI. >=20 >> the following actions are required and MUST be performed by the >> pledge: >>=20 >> o BRSKI: Request Voucher >> o EST: CA Certificates Request >> o EST: CSR Attributes >> o EST: Client Certificate Request >> o BRSKI: Enrollment status Telemetry >=20 > Actions? Operations? Steps? (Later you use the term operations.) >=20 > Would be good to clarify if the listed items are sending a message, or > performing a procedure called , or something else. Wording > here is quite loose. >=20 >> 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices >=20 > FWIW, it would have felt more natural to have thee requirements = specified in the > ANI documents, rather than here. >=20 >> The pledge goes through a series of steps, which are outlined here at >> a high level. >=20 > The Section 2.1 steps in the figure do not match the "actions" from > Section 1.5. >=20 >> 4. Imprint on the registrar. This requires verification of the >> manufacturer service provided voucher. A voucher contains >> sufficient information for the pledge to complete authentication >> of a registrar. (The embedded 'pinned-domain-certificate' >> enables the pledge to finish authentication of the registrar TLS >> server certificate). >=20 > There is a lot going on here. Might have been better to separate the > steps. >=20 >> After imprint a secure transport exists between pledge and registrar. >=20 > Do you mean there's an open TLS/TCP connection or that there are > credentials&keys to securely communicate between the two? >=20 >> The pledge goes through a series of steps, which are outlined here = at >> a high level. >>=20 >> ... >>=20 >> | +------v-------+ >> | | (6) Enrolled | >> ^------------+ | >> Factory +--------------+ >=20 > "Enrolled" is not a step, but rather a state... >=20 >> 2. Securely authentating the pledges identity via TLS connection to >=20 > typo >=20 >> 2. Securely authentating the pledges identity via TLS connection to >=20 > s/pledges/pledge's/? >=20 >> registrar. This provides protection against cloned/fake pledged. >=20 > s/pledged/pledge/? >=20 >> 3. Secure auto-discovery of the pledges MASA by the registrar via >> the MASA URI in IDevID as explained below. >=20 > I can't parse the sentence. >=20 >> 4. (Optionally) communicating the MUD URL (see Appendix C. >=20 > Missing closing paren. >=20 >> The following newly defined field SHOULD be in the PKIX IDevID >> certificate: >=20 > I didn't understand the formulation here. Are you defining one > (seems like it below) or are you referencing a newly elsewhere > defined field? Suggest a reformulation, e.g., "This document > defines a new field for PKIX certificates. These fields SHOULD > appear in the PKIX IDevID certificates when used with BRSKI." >=20 >> Specifically, the IDevID: >>=20 >> 1. Uniquely identifying the pledge by the Distinguished Name (DN) >> ... >> 2. Securely authentating the pledges identity via TLS connection to >> ... >> 3. Secure auto-discovery of the pledges MASA by the registrar via >> ... >> 4. (Optionally) communicating the MUD URL (see Appendix C. >>=20 >> 5. (Optional) Signing of voucher-request by the pledges IDevID to >> ... >> 6. Authorizing pledge (via registrar) to receive certificate from >=20 > There's something wrong with the language here. Maybe "Specifically, > the IDevID enables the following: 1. Unique identification of the ..." >=20 > Section 2.4 protocol flow is very different from the explanation > in Section 2.1, which does not show the role of the background > systems (MASA) at all. >=20 >> P | /---> | | >> P | | [accept device?] | >> P | | [contact Vendor] | >> P | | |--Pledge ID-------->| >> P | | |--Domain ID-------->| >> P | | |--optional:nonce--->| >> P | | | [extract DomainID] >> P | optional: | [update audit log] >> P | |can | | >> P | |occur | | >> P | |in | | >> P | |advance | | >> P | |if | | >> P | |nonceless | | >> P | | |<- voucher ---------| >> P | \----> | | >=20 > I had a difficulty in understanding the notation here. Is the > thing in the middle with the label "optional" a bracket that > shows a part of the flow can be at a different place? Or is it > some entity with some messages flowing from it, because it has > arrows? I think the format, but this is unclear. >=20 >> The registrar uses an Implicit Trust Anchor database for >=20 > Upon the first reference to the term you should include a > reference to RFC 7030. >=20 >> be-determined mechanism (such as an Intent) to become the local >=20 > Reference needed to "Intent". >=20 >> 4.2. CoAP connection to Registrar >>=20 >> The use of CoAP to connect from pledge to registrar is out of scope >> for this document, and may be described in future work. >=20 > I would just have said other mechanisms can be defined in future work. >=20 >> In the nonced case, validation of the registrar MAY be omitted if the >=20 > Nonced? >=20 >> assertion: The assetion leaf in the voucher and audit log indicates >=20 > Typo >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 10 13:46:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF598120307; Wed, 10 Jul 2019 13:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0QIN7BEap8_u; Wed, 10 Jul 2019 13:46:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4711203FC; Wed, 10 Jul 2019 13:46:04 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B5C133818E; Wed, 10 Jul 2019 16:43:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9CC3EA8A; Wed, 10 Jul 2019 16:46:01 -0400 (EDT) From: Michael Richardson To: Roman Danyliw cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:46:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will attempt to answer each substantive comment in a separate email, as I want to show the work in the form of a diff, and it will be too confusing to do it all at once. The tinyurl that I posted for Eric should remain valid as a cumulative diff as I push stuff to github, as rfcdiff will calculate again each time. Roman Danyliw via Datatracker wrote: > I support Eric=E2=80=99s Discuss position. Also a big thanks to Chris= tian > Huitema=E2=80=99s thorough SECDIR reviews and the associated improvem= ents made > as a result. I have a few more items: Could you specifically comment on Eric's comment about domainID being a SHA-1 Hash of the PublicKeyInfo > (1) Section 5.7. The format of a pledge status telemetry message see= ms > underspecified. Fair enough. In the interop testing that has occured online and in-person since November, we have actually not gotten to this point yet. > ** what are all of the fields (e.g., version appears in the example b= ut > no the text) added version and text about how a registrar should behave when it sees a version larger than it understands. > ** what are the field formats (e.g., the format of the status field is > inferred from the unlabeled example > ** which fields are mandatory? > ** Per the JSON snippet, is that normative is some way in describing > the format? > ** Also, how does a server receiving the telemetry messages behave wh= en > receiving unexpected JSON attributes? I have made these changes: https://github.com/anima-wg/anima-bootstrap/commit/dd17db4f1c39b2332e6f4987= 7a0a0fccd1dd5a6f diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml index 610150d..9aa2a2a 100644 =2D-- a/dtbootstrap-anima-keyinfra.xml +++ b/dtbootstrap-anima-keyinfra.xml @@ -2101,41 +2101,69 @@ locator3 =3D [O_IPv6_LOCATOR, fe80::1234, 41, nil]= ]]> status. To indicate pledge status regarding the voucher, the pledge =2D MUST post a status message. + MUST post a status message to the Registrar. The posted data media type: application/json The client HTTP POSTs the following to the server at the EST we= ll =2D known URI "/voucher_status". The Status field indicates if the v= oucher =2D was acceptable. If it was not acceptable the Reason string indic= ates =2D why. In the failure case this message may be sent to an =2D unauthenticated, potentially malicious registrar and therefore t= he =2D Reason string SHOULD NOT provide information beneficial to an =2D attacker. The operational benefit of this telemetry information = is =2D balanced against the operational costs of not recording that an =2D voucher was ignored by a client the registrar expected to contin= ue =2D joining the domain. + known URI "/voucher_status". + + + The format and semantics described below are for version 1. + A version field is included to permit significant changes to this + feedback in the future. A Registrar that receives a status + message with a version larger than it knows about SHOULD log the + contents and alert a human. + + + The Status field indicates if the voucher was acceptable. + Boolean values are acceptable. + + + + If the voucher was not acceptable the Reason string indicates + why. In the failure case this message may be sent to an + unauthenticated, potentially malicious registrar and therefore t= he + Reason string SHOULD NOT provide information beneficial to an + attacker. The operational benefit of this telemetry information = is + balanced against the operational costs of not recording that an + voucher was ignored by a client the registrar expected to contin= ue + joining the domain. + =2D
=2D =2D
The server SHOULD respond with an HTTP 200 but MAY si= mply =2D fail with an HTTP 404 error. The client ignores any response. Wi= thin =2D the server logs the server SHOULD capture this telemetry =2D information. The reason-context attribute is an arbitrary JSON object (literal value or hash of values) which provides additional information specific to this pledge. The contents of this field are not subject to standardization. + + + The version, and status fields MUST be present. + The Reason field SHOULD be present whenever the status field + is negative. The Reason-Context field is optional. + + + The keys to this JSON hash are case-insensitive. + + +
+ +
+ The server SHOULD respond with an HTTP 200 but MAY simply + fail with an HTTP 404 error. The client ignores any response. Wi= thin + the server logs the server SHOULD capture this telemetry + information. + Additional standard JSON fields in this POST MAY be added, see =2D . + . A server that + sees unknown fields should log them, but otherwise ignore them. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mTokACgkQgItw+93Q 3WXaVAf+IImEhDoA7JF/xIYLoU+diE5bMQSOYsW25QRSwuMoj3tw8eNeWtNB5hPa Iu2Y9a7t76wJeTGdiEdAaX3Wrif8wLseYxeXxG0Gf9J1Cmf6VqAVL15t5Mch/N14 dVRA3WfvR3bocZbymuhhl2GobBDKAKFauXLLDWZU1GI0oFmnIwNGpN+jniQPuV4m +LWGI1ly9nSVOsVhlZAPXRUNu/IpnCefMBdAZDVOo8FLX01mJchNEXfUG4Bn2k5z srZMAoTkS1z2Dy36Xdmk2VC1vR0PenK6nD6SKJRIiPSpXYOZZebKQEaZgwD6C1X+ dkmvoLf27wYSKh2wOjrx13hhzw5o3w== =l0p5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 13:51:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E5612014E; Wed, 10 Jul 2019 13:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 O5HCixRAVTfD; Wed, 10 Jul 2019 13:51:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC332120147; Wed, 10 Jul 2019 13:51:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E39F3818E; Wed, 10 Jul 2019 16:49:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 19BFBA8A; Wed, 10 Jul 2019 16:51:23 -0400 (EDT) From: Michael Richardson To: Roman Danyliw cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:51:27 -0000 --=-=-= Content-Type: text/plain Roman Danyliw via Datatracker wrote: > (2) Section 5.8.1. The format of the MASA audit log seems > underspecified. Is the JSON snippet presented here normative to > describe the MASA audit log > response? Yes, it's intended to be normative. How can we make it clearer without over-engineering this, remembering that this is a PS, not IS, and the proof will be in the running-code. Would you prefer to used CDDL or something like that to describe it? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mT8oACgkQgItw+93Q 3WW3GQf/SVoX1mgggXwFbcWzgyAf7eMbHaPvIcQ5ILsBNcEHCLOtR1pZSV6tgrDM zn2TqJwVrv9s45UmqO+aTAGfwLsX5GcscLI36iDtd5bl2BrTRK9UrQlePnIntlKk 1ZNYmeAgoxckqeLFf74rDQnLctgEzkt8GSL8kjAn6XjdioZ7tuTWkp5OH0qFMIiJ 182TJMl7fh/M7RHzYMzE7zk49MeoTTlobVAX5u5NdfLXPQpoBnrE5tUjUEfsSRt1 1cv47OEqNTJvYD7/Xss1oBZk3vvxydeCwCIfy0ms/hWWPhHS4YnRGcLDJLtAUya7 bbrtmmNxPGIrAkvj+S2xgiF30GTw4Q== =yh1h -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 13:59:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31212001B; Wed, 10 Jul 2019 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2POHPgRwqOtH; Wed, 10 Jul 2019 13:59:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4CC120025; Wed, 10 Jul 2019 13:59:35 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F6A13818E; Wed, 10 Jul 2019 16:57:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7762FA8A; Wed, 10 Jul 2019 16:59:34 -0400 (EDT) From: Michael Richardson To: Roman Danyliw cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:59:38 -0000 --=-=-= Content-Type: text/plain Roman Danyliw via Datatracker wrote: > (3) Why is Section 7.x in this document if it explains how to use BRSKI > but is > considered non-normative? > -- How should implementers take this language? > -- Why are normative sections, like Section 11, discussing it? 1) It's non-normative for proper/full operation of the ANIMA ACP 2) We think that some of the mechanisms that 7.2 describes may be needed in order for operators to have ways to work around infrastructure failures, such as manufacturers going out of business. We don't want to standardize I see that we use 2119 language in this section, and maybe that does not belong. or maybe the section should be normative, but consist of a series of "MAY" statements? If vendors are going to provide work arounds ("back-doors") it would be best if they did something we can identify and reason about. So to use the back-door to the building analogy: we want to define fire-exits in the building code rather that doors that are insecure. A lot of the text in Section 7 was originally sprinkled elsewhere, but that confused things. As shown by the long thread from concerned operators, this move towards a secure-onboarding-by-default scares people who are used to improvising things in an emergency. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mUbYACgkQgItw+93Q 3WWjiQgAquwTkGckjM+9fSCVOcaoZ13vKAQzLrBayyCPHd9toAVVaKd27Dy71Bc1 mqOzTJCVLMM0bICgq4IwmhW4O9ZBNPObOQOMyqcjT3KLBgaH6m/jZwTNXNMCHmNj k8gGAYpXXIHqTPjJtP7CGB+GhGPY/80FLzMentuPu9a4LPWfObtTBmdnwVDri0mg K8LeRcNt4YkI7vuHng7gpiQUS7tpfCVmflgMTjNDwGIsgekchwOd1QwjXQkRwzQ3 yDny2+8mHygkUSJw7ACMHxkvGzg4RX2RvYI0gY9ikF5QGjgQ2Vw175KTGrECK7LY /Wr6R4OWBkBNLjL6NQ8Y1lCSIMUkjw== =IL/N -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 14:15:23 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7EE1200B6; Wed, 10 Jul 2019 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Bs3qJvJ8deNu; Wed, 10 Jul 2019 14:15:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F667120025; Wed, 10 Jul 2019 14:15:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B10C03818E; Wed, 10 Jul 2019 17:13:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A1F21729; Wed, 10 Jul 2019 17:15:17 -0400 (EDT) From: Michael Richardson To: Roman Danyliw cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 21:15:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roman Danyliw via Datatracker wrote: > (4) Thank you for documenting =E2=80=9Cmanufacturer control issues=E2= =80=9D in Sections > 10.3 and 10.4. It helpfully lays justifies the current design > approach. I strongly concur with the premise that =E2=80=9Cfacilitat= e[ing] a > few new operat[i]onal modes without making any changes to the BRSKI > protocol=E2=80=9D is exactly what is needed. > My concern is that even with the current applicability statement in > Section 9, the current text appears to have only standardized the fir= st > part of the lifecycle that BRSKI equipment might see -- equipment on > first sale as long as the manufacturer supports it or stays in > business. The text doesn=E2=80=99t appear to cover the practical asp= ects of > the proposed mitigations in Section 10.5 or the situations described = in > Section 10.3/10.4 =E2=80=93 various situations possible in the full l= ifecycle > usage of a BRSKI device and needed support the =E2=80=9Cadditional op= erational > modes=E2=80=9D. Specifically: > ** There appears to be little discussion on how > owners/manufacturers/vendors can facilitate second sale/used equipment > beyond narrative words (in Section 10.3 and 10.4) > ** There is appears to be little discussion on how to practically > implement a MASA (i.e., the offline use case). For example, (Per > Section 10.5) =E2=80=9CA manufacturer could provide a mechanism to ma= nage the > trust anchors and built-in certificates (IDevID) as an extension. Th= is > is a substantial amount of work, and may be an area for future > standardization work=E2=80=9D. Without the ability to change anchors= on the > device the additional operational modes such as offline mode seems > challenging. Our goal here has been to provided bootstrapping... the beginning of the lifecycle. It would be great to be able to provide full lifecycle specification. There are quite a number of non-technical issues (i.e. layer 8 and 9) involved in supporting a second sale process. Updating the trust anchors that are used to verify the voucher is, I think, a pretty big deal, and I just don't see that we can deal with this in a general way for a variety = of product types. Some vendors would see this as meaning that the TPM has to be opened up. Some operators would be concerned that if this was possible, that they would no longer be able to be certain that a secure boot process would still be secure. I would be happy if this work was chartered a "RATS 2.0", or became part of NETMOD. I don't see how we can do justice in this document. As for operational notions as to how to operator a MASA, and as you say, one that supports off-line vouchers, I agree that we are not that helpful. Note that off-line vouchers are ones without nonces and without expiry date= s, transfered to the Registrar by store-and-forward (USB key, scan from QR code on invoice, etc.). They are still signed by the primary manufacturer, and still bind to the primary owner. They are not bearer tokens, and they do not require changes to the trust anchors, and they do n= ot facilitate second sale. Perhaps there is something I can change in that section to clarify this poi= nt. To use an HTTP 0.9 analogy, it's like asking the http (1.0) WG to comment on how whether Model-View-Controller vs Presentation-Abstraction-Control is the right way to build social media sites. Having said that, I am pretty sure that we need to write an Operational Considerations document for both MASA and Registrar. I suspect that the first draft will mostly be a list of things not to do. ("Doctor it hurts wh= en I move my harm like this...") =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mVWUACgkQgItw+93Q 3WV7Gwf/b5oyfKOqPXPzF9CQ8y2j4rlsIqj8cWDTj5K2n9lK0q92IgRZ84fATkay thQp407jqUmcLhgn4fAvEVnxJhlSZH7AouJJQKHNq6VfDJg7/HCb2fwZtprjQ+Nl Tw2G8UX9ZYQzHS01twwTwUxvpmEZVCyiiD+5RRTfqgTFzAF7c5mkErnPjeF8kcfG EJHt7KKwea9CEqfr8ZcLv5r3Vz8enCrAug9Wl/Iw88GOjh3U6HivHdOh6NyfR6Vr cb/p6fileRIEBCMDjURA0RJAL4AJZUmIrUd/BDXb18zRi8Lv5F8oAmVxNVuuiUD8 IRgFM7YJEnileCFNRNdESGUIQcrdLw== =x5qR -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 17:34:59 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42447120024; Wed, 10 Jul 2019 17:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7WajnXyA7GRp; Wed, 10 Jul 2019 17:34:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85264120019; Wed, 10 Jul 2019 17:34:43 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E1C83818F; Wed, 10 Jul 2019 20:32:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 29AEA729; Wed, 10 Jul 2019 20:34:42 -0400 (EDT) From: Michael Richardson To: Roman Danyliw , max pritikin , "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 00:34:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roman Danyliw via Datatracker wrote: > (5) Section 1.3.2. Cite the origin of the taxonomy which defines > =E2=80=9Cclass 2+=E2=80=9D devices =E2=80=93 likely RFC7228 done. > (6) Section 1.5. Per =E2=80=9CUpon successfully validating a voucher= artiface, a > status telemetry MUST be returned.=E2=80=9D, what is a =E2=80=9Cvouch= er artiface=E2=80=9D? is > that just a =E2=80=9Cvoucher=E2=80=9D? It's a typo. It should be voucher artifact. We used "Voucher Artifact" all over RFC8366. > (7) Section 2.6.1. What is a =E2=80=9CNetwork Time Protocols=E2=80= =9D =E2=80=93 specifically > why is protocols plural? Is this something more than NTP? Yes, NTPv4, but it could also be IEEE PTP, or even GSM. It doesn't much matter... no network =3D=3D> no network time. > (8) Section 4.1. Per =E2=80=9CThe communication between the pledge i= s over IPv6 > Link-Local addresses=E2=80=9D, if that is the case, why does Figure 3= show IPv4 > and Appendix A describes an IPv5 approach? Because some members of the WG continued to complain that IPv6 isn't ubiquitous, and Appendix A was the compromise. I would be happy to rip it out, because I think the argument is specious. > (9) Section 5.1., Per =E2=80=9CThe pledge maintains a security parano= ia > concerning the provisional state =E2=80=A6=E2=80=9D, what does it mea= n to =E2=80=9Cmaintain a > security paranoia=E2=80=9D? I guess I don't know. Max? Seems like useless words. > (10) Section 5.1. Per =E2=80=9CA pledge that can not maintain as many > connections as there are eligible proxies.=E2=80=9D, this is an unfin= ished > sentence. What should the pledge do? fixed. A pledge that can not maintain as many connections as there are - eligible proxies. If no connection is making progess after 5 secon= ds - then the pledge SHOULD drop the oldest connection and go on to a - different proxy: the proxy that has been communicated with least - recently. If there were no other proxies discovered, the pledge MAY - continue to wait, as long as it is concurrently listening for new - proxy announcements. + eligible proxies will need to rotate among the various choices, + terminating connections that do not appear to be making progress. = If + no connection is making progess after 5 seconds then the pledge + SHOULD drop the oldest connection and go on to a different proxy: t= he + proxy that has been communicated with least recently. If there were + no other proxies discovered, the pledge MAY continue to wait, as lo= ng + as it is concurrently listening for new proxy announcements. > (11) Section 5.2. created-on. The value to use in this field of this > field is not described here. =2D RECOMMENDED to populate this field. This provides additional =2D information to the MASA. + RECOMMENDED to populate this field with the current date and + time in yang:date-and-time format. This provides additional =2D information to the MASA. > (12) Section 5.2. Per =E2=80=9CAll other fields MAY be omitted in th= e pledge > voucher-request=E2=80=9D, should this be read as guidance that the fi= elds > mentioned above this text are mandatory (i.e., created-on, nonce, > proximity-registrar-cert). If so, what value should pledges without > clocks use? I guess: Pledges that have no real-time clocks MAY omit this field. > (13) Section 5.3. Per =E2=80=9CIf these validations fail the registr= ar SHOULD > respond > with an appropriate HTTP error code=E2=80=9D, a few questions: Ha, I kept asking for us to be specific about error codes, but I missed this part. =2D If these validations fail the registrar SHOULD respond with an =2D appropriate HTTP error code. + If these validations fail the registrar SHOULD respond with the + HTTP 404 error code. If the voucher-request is in an unknown + format, then an HTTP 406 error code is more appropriate. + A situation that could be resolved with administrative action + (such as adding a vendor to a whitelist) MAY be responded with an + 403 HTTP error code. > ** Is this text suggesting that silent failure? Given the text says > SHOULD, > validation could fail and the registrar would not share this failure? > ** What specific codes should be used? I believe that there may be other error codes that would make sense, so I'm sticking with SHOULD. > (14) Section 5.4. Per =E2=80=9CThe registrar initiates the connectio= n and uses > the MASA URL obtained as described in Section 2.8 for [RFC6125] > authentication of the MASA.=E2=80=9D, RFC6125 doesn=E2=80=99t have a = Section 2.8. > Please clarify how this connection is made. aha. It's section 2.8 of this document! Some punctuation is missing. =2D for =2D authentication of the MASA. + . The mechanisms in + SHOULD be used authentication of the + MASA. Some vendors will establish explicit (or private) trust + anchors for validating their MASA; this will typically done as + part of a sales channel integration. Registars SHOULD permit + trust anchors to be pre-configured on a per-vendor basis. > (15) Section 5.5. What is the relationship between the value of the > created-on field passed by the pledge per Section 5.2, and described = in > Section 5.5 as being populated by the registrar. =2D Registrars are RECOMMENDED to popula= te this field. This provides additional information to the MASA. + + The Registrars SHOULD populate this field with the current date = and + time when the Registrar formed this voucher request. This field + provides additional information to the MASA. + > (16) Section 5.5. What is a =E2=80=9Cstatistically unique identity=E2= =80=9D per the > =E2=80=9Cidevid-issuer=E2=80=9D field? Max? I don't think the word statistically is useful here. The serial-number extracted from the pledge IDevID is unique per IDevID issuer, so we include that here. I realize that my implementation does not include this at all, and I just use the certificate from the prior-signed-voucher-request. > (17) Section 5.7. Per the JSON snippet: > ** It isn=E2=80=99t labeled as a figure or example; and isn=E2=80=99t= referenced in the > text. > ** This isn=E2=80=99t valid JSON: no commas between items. What does= the > notation =E2=80=9C/* > TRUE=3DSuccess, FALSE=3DFail=E2=80=9D=E2=80=9D mean =E2=80=93 opening= with a /* and closing with a =E2=80=9C? fixed. I need to go back throuth an renumber the figures (or rather,use anchors). > (18) Section 5.8.2. Per =E2=80=9CEach time the Manufacturer Authoriz= ed Signing > Authority (MASA) issues a voucher, it places it into the audit log for > that device. The details are described in Section 5.8.=E2=80=9D, this > reference to Section 5.8 on how the MASA logs doesn=E2=80=99t seem co= rrect. > Section 5.8 describes how a > registrar asks a MASA about its logs. Each time the Manufacturer Authorized Signing Authority (MASA) =2D issues a voucher, it places it into the audit log for that d= evice. =2D The details are described in . + issues a voucher, it appends details of the assignment to + an internal audit log for that device. + The internal audit log is processed when responding to + requests for details as described in . Does this work for you? It is not our intend to specify how the internal audit log works, just what it must be able to produce. > (19) Section 5.9.4. What happens if the pledge doesn=E2=80=99t re-ne= gotiate an > EST TLS session after been successful enrolled? I'm not sure. Max? > (20) Section 5.9.4. In what way is a the SubjectKeyIdentifier includ= ed > in the success telemetry message? If there is success, I don't think the SubjectKeyIdentifier needs to be logged. If there is failure, then the idea was that it would go into the reason in some textual form. > (21) Section 6. What is =E2=80=9C../voucherrequest=E2=80=9D? It's a typo for /requestvoucher! > (22) Section 7. Per =E2=80=9CThis section is considered non-normativ= e: use > suggested methods MUST be detailed in specific profiles of BRSKI=E2= =80=9D -- > the clause after the colon doesn=E2=80=99t parse. What is the guidan= ce > relative to profiles? How about: This section is considered non-normative: use of the suggested mechanism here MUST be detailed in specific profiles of BRSKI. This is a subject for future work. I don't understand "What is the guidance relative to profiles?" > (23) Section 11.0. The caution about untrusted data and HTTP librari= es > seems warranted. Wouldn=E2=80=99t this also apply to the application= code too? In what way to do you mean? Maybe this paragraph has been mis-understood. We are trying to say that despite the headers and content being untrusted, that mature HTTP libraries should not be particularly vulnerable. Is that what you understood? > (24) Section 11.1. Per the list of examples where a MASA is > unavailable or uncooperative, wouldn=E2=80=99t a manufacturing going = out of > business also be a concern? Absolutely. One reason why we call it the Manufacturer *AUTHORIZED* signing authority, is that we believe that this is something Manufacturers will outsource, and buyers will insist that there is an escrow plan. > (25) Section D.1.4. Provide an openssl version and reference that > generated this output Well, it was done with libcrypto 1.1.1c, from (open source ruby) code linked against it. I can certainly say that, but I don't know what "reference" means here. > (26) Per Christian Huitema=E2=80=99s Last Call SecDir Review > (https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-key= infra-20-secdir-lc-huitema-2019-06-04/), > please respond to the last two issues =E2=80=93 random number generat= ion and the > missing assertion leaf. I had not seen this second review, thank you. I will read this on Thursday and post additional changes. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mhCEACgkQgItw+93Q 3WVGSAgAvkjitd+RHDMCdP7QDemkw5C1UzcWXXE2ajqoTs2Q/h0VIzHLVmzTtQTb nMEBpHtB+vGlFYo1+xvwSoARc+1j0kUx0XiXKjAOoLNHNvTXgs22xs3ar+pWUqQX +pUoU3Qs26X5o7qChofeX1dvTwxbq38fWydbAJimU3E727Tnyz7PkV+qFgKzFqKY K7pMJrOfHSWgSd29fHIjnnk3VEYmWsgh+ziqKvOdQAUYZgqoXfvWfYJ9ESIhYKYS Az3kkcfM1jehy43NmuUmhwmRa1AWtw7oKbF/KKv9QJwSzF9bdXtVFbjZMecIVeu4 Et/BYUFLhWBRZQok50MrDDXZf5/JMQ== =1tMI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 19:56:33 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E70120098; Wed, 10 Jul 2019 19:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 utxry8mvJDd4; Wed, 10 Jul 2019 19:56:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510E3120019; Wed, 10 Jul 2019 19:56:27 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E3A853818F; Wed, 10 Jul 2019 22:54:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 31598A8A; Wed, 10 Jul 2019 22:56:26 -0400 (EDT) From: Michael Richardson To: Alissa Cooper cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 02:56:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Alissa Cooper via Datatracker wrote: > I apologize if I'm misunderstanding how this works, but I didn't see = much > discussion in the document about the implications of the manufacturer= going out > of business. Specifically, it seems like if a device ships with BRSKI= as its > only available mechanism for bootstrapping and the manufacturer goes Section 7 provides some detail on a number of mechanisms that a manufacturer could chose to include that would permit a device to be onboarded with reduces levels of trust. Section 7.2 specifically mentions onboarding via serial-console. (This situation is really no different from buying an iPhone 4 and then complaining that you can't make it work because Apple won't give you software that is secure, and since it's insecure, they won't onboard you, except that you get a serial-console) > =3D Section 1.3.1 =3D > "But this solution is not exclusive to large equipment: it is intended > to scale to thousands of devices located in hostile environments, > such as ISP provided CPE devices which are drop-shipped to the end > user." > I don't quite understand how this squares with the scope limitation d= escribed > in Section 1 and Section 9. If the whole network is professionally ma= naged by > the ISP, what part would be the "hostile environment"? The thousands of CPE devices (cable modems, VDSL modems, ISP provided home routers) can be taken apart by the home owner. If such devices have IDevID in a TPM module, then enrollment can be done securely. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I think this document would benefit from two concise lists, with note= s about > which items in each list are defined in this document and which ones = are not > defined: (1) what is operationally required of a manufacturer to supp= ort BRSKI, > and (2) what is operationally required of a domain owner to support > BRSKI. We did start this document describing the protocol from the point of view of each party (Pledge, Proxy, Registrar and MASA). This would be the way that each instrument in an orchestra receives their music. We found that readers found it very difficult to understand the big picture, so we now describe the protocol in time-sequence, the way that the script f= or a play would be described. But, you are asking for Operational requirements, not protocol requirements. I agree that this would be useful, and it's something that I'd like to writ= e. I would consider it more of a BCP, and I don't think we have the experience to write this down yet. > =3D Section 2.3.1 =3D > What precisely is meant by "TPM identification"? Could a citation be = provided? I don't have a reference, I hope Max can provide one. I imagine it would point to a TCG document. It's a SubjectAltName extension that is in a TPM contained certificate that tells relying parties what TPM device it is. > =3D Section 10.1 =3D > "The domain can maintain some privacy since it has not necessarily be= en > authenticated and is not authoritatively bound to the supply chain." > What does this mean? That the domain can expect the manufacturer not = to trust > the domainID because it hasn't been authenticated? The MASA has a list of devices, and for each device, it has a list of curre= nt and previous owners. This is the audit log. The MASA will disclose this to current and previous owners, if they can present a voucher-request that was From=20the device. (section 5.8) It's hard to understand what kind of attack there is, but imagine that xyz.= example.net goes under, sells a huge stack of example.com 48-port 100G BFRs to other ISPs. (The manufacturer, example.com is still alive and well, and is happy to take 10% support contracts from 30 new customers as it authorizes the resale) Someone gets the Registrar database from xyz. They can now discover who ownes all these BFRs... and(?)...profit. Perhaps this needs to be coordinated with resale of some other device. That can be done as, although the audit log does not list the actual customer, it lists them by SHA-1 hash of public key. So the sentence above notes that it's not like the Registrar told the manufacturer who it was, if it didn't authenticate. As such, either xyz.example.net or the new owners could generate a new domainID, and register each device uniquely. (They want to use some kind of ONION routing to obfuscate their IP address too, but that's instantly defeated if they authenticate with TLS 1.2 using a ClientCertificate) I'm sure that we could improve this examplanation, but I'm not exactly sure how yet. > =3D Section 10.2 =3D > "The above situation is to be distinguished from a residential/ > individual person who registers a device from a manufacturer: that an > enterprise/ISP purchases routing products is hardly worth mentioning. > Deviations would, however, be notable." > What does the last sentence mean? A residential ISP that buys 10,000 Linksys CPE routers is unremarkable. When the same ISP buys 10,000 Internet connectable sex toys as well, that might represent some kind of change in business plans. Would a PC vendor be interested if some Enterprise customer suddenly bought only tablets? The BRSKI-MASA connection does not reveal what is bought, but it does reveal who is doing business with whom, and it may also reveal volume. This is just traffic analysis. Christian Hopps has a nice document on defeating tha= t, btw. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0mpVkACgkQgItw+93Q 3WWTQAgArE4ecqTLP6sxVjp9ztnRjwDvREWJnHXqsCNZRqNghvhm+js5uxFGdZrs gVzgN6KZYyuJE0ZjYD77gTOSLNTzbma50QlQ6qI7Sz86Qhe0shqd01bjAzyaxG38 EJ8u44xQs/eOFLKKkGOm/6WecWduTx+D/S1SWfIROvgYp+RVS1+uFmmoWTEHbhI2 ayC9xkuqqQIuVvvxzYcWdd8fsGpFyyEenGpOMv2+ECqUE3mes0UB7mkarwHcZ6Qs OXfNrHE9bMvc1jOBat74rPsvzO2jRhn2thfU5XXr0exIfBiAmE/EbTSqa6CbuAtZ OJnG896pQ/ECle6mzK/50KQ4fItuPw== =zGBU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 10 20:36:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B51E120090; Wed, 10 Jul 2019 20:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=N6mc6byZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T1eFekTh 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 ZmcV8sD8X-Gq; Wed, 10 Jul 2019 20:36:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B62F120098; Wed, 10 Jul 2019 20:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18274; q=dns/txt; s=iport; t=1562816160; x=1564025760; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NwU7GrHaZgVKWXttGn606VkwRKvVe1+dqGz4RJTOZSs=; b=N6mc6byZoUKd/c1zsxEOMMYPU+yR/HdEHNBJQYN1mSAm9h21pGvbmSgd Hu3Kwxk0P5UgMGAgL6HvfI5t5TRFPQvOoBGwKSFCA1JydYnuMfkB6BgAp Tb+CZdGRpPhl+NqeLLkypGwmmn5v35xRcz8Ywn5eBujow7lURR/pixROV A=; IronPort-PHdr: =?us-ascii?q?9a23=3A98+sYxOXcFoE6lAM5b0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjNv/2bi87GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAAA7riZd/5FdJa1cCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWeBRCQsA2pVIAQLKAqEEoNHA45FgjYlfpZLgUKBEANUCQE?= =?us-ascii?q?BAQwBAScGAgEBgUuCdQIXgjcjOBMBAwEBBAEBAgEFbYU8DIVKAQEBAwESERE?= =?us-ascii?q?MAQEwBwEECwIBBgIYAgIfBwICAjAVEAIEDgUigwABgWoDDg8BAgyRD5BgAoE?= =?us-ascii?q?4iGBxgTKCeQEBBYE2AgELAkABgnsYghIJgQwoi18XgX+BEScME4IXNT6CYQI?= =?us-ascii?q?DAYEhEhQWgwoygiaMDigcgiCbaAkCghmGWIlAg3AbgiyHIoQMiieMUQmIGJA?= =?us-ascii?q?AAgQCBAUCDgEBBYFnIYFYcBU7KgGCQQmCODeCZlSFFIU/coEpi14rgQQBgSA?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.63,476,1557187200"; d="scan'208";a="591780790" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 03:35:58 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x6B3ZwWN004587 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jul 2019 03:35:58 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Jul 2019 22:35:57 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 10 Jul 2019 23:35:56 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 10 Jul 2019 22:35:56 -0500 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=NwU7GrHaZgVKWXttGn606VkwRKvVe1+dqGz4RJTOZSs=; b=T1eFekThIr9LMHmGh5aoS9HT7TVpsKwEFd8DYc4tkT0ljxKV34fBQ2c4SsQRdTRx72kCOSk14U8lB9nhalwfsHaKvp195ztgAvVSQIayy9XKYYi7ViACNDFN357mk2rjMmO7jTa9zMOB9tR2gmegnnhWVjebcgaMbKFgGd0RezM= Received: from BYAPR11MB3525.namprd11.prod.outlook.com (20.177.227.23) by BYAPR11MB3014.namprd11.prod.outlook.com (20.177.225.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 03:35:55 +0000 Received: from BYAPR11MB3525.namprd11.prod.outlook.com ([fe80::cc5d:56b1:d49d:40b0]) by BYAPR11MB3525.namprd11.prod.outlook.com ([fe80::cc5d:56b1:d49d:40b0%6]) with mapi id 15.20.2052.020; Thu, 11 Jul 2019 03:35:55 +0000 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: Roman Danyliw , The IESG , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , Toerless Eckert , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) Thread-Index: AQHVNzqkCycerXks7k23GfVFedpIyqbEkmYAgAAyngA= Date: Thu, 11 Jul 2019 03:35:54 +0000 Message-ID: References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> <16705.1562805282@localhost> In-Reply-To: <16705.1562805282@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pritikin@cisco.com; x-originating-ip: [72.163.2.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41ffa2d0-b1c9-458c-c668-08d705b0e174 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3014; x-ms-traffictypediagnostic: BYAPR11MB3014: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(136003)(396003)(39860400002)(189003)(199004)(66476007)(81166006)(81156014)(6116002)(7736002)(53546011)(26005)(316002)(66446008)(66946007)(8676002)(8936002)(66066001)(64756008)(6486002)(76116006)(30864003)(66556008)(2906002)(186003)(6506007)(11346002)(6512007)(3846002)(486006)(256004)(86362001)(476003)(102836004)(5660300002)(14444005)(6436002)(446003)(25786009)(6246003)(53936002)(71200400001)(36756003)(71190400001)(68736007)(229853002)(2616005)(33656002)(305945005)(4326008)(54906003)(76176011)(966005)(99286004)(14454004)(6306002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3014; H:BYAPR11MB3525.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: chaffL2k3esezfL8j1f75e/Ne9D86bx2yn/rd9WkCS4BJ0T2Ua9G0jxgRd2Qr23XHV6i8IdgxjTltTOQQ4P9+ksOKh4pu2Pfa9+KrF+60QR5arJkkb7IEY38aGfLa6rlqvEghZ5G6k+nfFW+oz8AzyHnO6Aj3nTwLmV/x/aHYlHyFsk/8bpEVj190Ph2kb4uyta5mbcnfV6bAjAeNG60mkC976X6I2mBQ9D7cOQTlBSYLvJq9KHr+cV9QmMG6gFTkhfdeDsFqaJ4TYGK3CDNi79WcjPlYkPVBNWN/g7W7CCCgm3zOKxyrdT4F2m++4QpzlnJcFpxDpPSq6WBN1Gh9eoKuLTofIrUiZ0VahBK9wERFbCC4q/s5HUVzanG5E7cyhZ8HqFKLzU0Bsvj1huVLArsfzZNPTj/4dZ+TkU+aTk= Content-Type: text/plain; charset="utf-8" Content-ID: <8BF0203FD31745478C5F17C0DC3F2C5D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41ffa2d0-b1c9-458c-c668-08d705b0e174 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 03:35:54.9714 (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: pritikin@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3014 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 03:36:05 -0000 aW5saW5lIGNvbW1lbnRzLCANCg0KPiBPbiBKdWwgMTAsIDIwMTksIGF0IDY6MzQgUE0sIE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IA0KPiBS b21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+ PiAoNSkgU2VjdGlvbiAxLjMuMi4gIENpdGUgdGhlIG9yaWdpbiBvZiB0aGUgdGF4b25vbXkgd2hp Y2ggZGVmaW5lcw0KPj4g4oCcY2xhc3MgMivigJ0gZGV2aWNlcyDigJMgbGlrZWx5IFJGQzcyMjgN Cj4gDQo+IGRvbmUuDQo+IA0KPj4gKDYpIFNlY3Rpb24gMS41LiAgUGVyIOKAnFVwb24gc3VjY2Vz c2Z1bGx5IHZhbGlkYXRpbmcgYSB2b3VjaGVyIGFydGlmYWNlLCBhDQo+PiBzdGF0dXMgdGVsZW1l dHJ5IE1VU1QgYmUgcmV0dXJuZWQu4oCdLCB3aGF0IGlzIGEg4oCcdm91Y2hlciBhcnRpZmFjZeKA nT8gIGlzDQo+PiB0aGF0IGp1c3QgYSDigJx2b3VjaGVy4oCdPw0KPiANCj4gSXQncyBhIHR5cG8u IEl0IHNob3VsZCBiZSB2b3VjaGVyIGFydGlmYWN0Lg0KPiBXZSB1c2VkICJWb3VjaGVyIEFydGlm YWN0IiBhbGwgb3ZlciBSRkM4MzY2Lg0KPiANCj4+ICg3KSBTZWN0aW9uIDIuNi4xLiAgV2hhdCBp cyBhIOKAnE5ldHdvcmsgVGltZSBQcm90b2NvbHPigJ0g4oCTIHNwZWNpZmljYWxseQ0KPj4gd2h5 IGlzIHByb3RvY29scyBwbHVyYWw/ICBJcyB0aGlzIHNvbWV0aGluZyBtb3JlIHRoYW4gTlRQPw0K PiANCj4gWWVzLCBOVFB2NCwgYnV0IGl0IGNvdWxkIGFsc28gYmUgSUVFRSBQVFAsIG9yIGV2ZW4g R1NNLg0KPiBJdCBkb2Vzbid0IG11Y2ggbWF0dGVyLi4uIG5vIG5ldHdvcmsgPT0+IG5vIG5ldHdv cmsgdGltZS4NCj4gDQo+PiAoOCkgU2VjdGlvbiA0LjEuICBQZXIg4oCcVGhlIGNvbW11bmljYXRp b24gYmV0d2VlbiB0aGUgcGxlZGdlIGlzIG92ZXIgSVB2Ng0KPj4gTGluay1Mb2NhbCBhZGRyZXNz ZXPigJ0sIGlmIHRoYXQgaXMgdGhlIGNhc2UsIHdoeSBkb2VzIEZpZ3VyZSAzIHNob3cgSVB2NA0K Pj4gYW5kIEFwcGVuZGl4IEEgZGVzY3JpYmVzIGFuIElQdjUgYXBwcm9hY2g/DQo+IA0KPiBCZWNh dXNlIHNvbWUgbWVtYmVycyBvZiB0aGUgV0cgY29udGludWVkIHRvIGNvbXBsYWluIHRoYXQgSVB2 NiBpc24ndA0KPiB1YmlxdWl0b3VzLCBhbmQgQXBwZW5kaXggQSB3YXMgdGhlIGNvbXByb21pc2Uu DQo+IEkgd291bGQgYmUgaGFwcHkgdG8gcmlwIGl0IG91dCwgYmVjYXVzZSBJIHRoaW5rIHRoZSBh cmd1bWVudCBpcyBzcGVjaW91cy4NCj4gDQo+PiAoOSkgU2VjdGlvbiA1LjEuLCBQZXIg4oCcVGhl IHBsZWRnZSBtYWludGFpbnMgYSBzZWN1cml0eSBwYXJhbm9pYQ0KPj4gY29uY2VybmluZyB0aGUg cHJvdmlzaW9uYWwgc3RhdGUg4oCm4oCdLCB3aGF0IGRvZXMgaXQgbWVhbiB0byDigJxtYWludGFp biBhDQo+PiBzZWN1cml0eSBwYXJhbm9pYeKAnT8NCj4gDQo+IEkgZ3Vlc3MgSSBkb24ndCBrbm93 Lg0KPiBNYXg/ICBTZWVtcyBsaWtlIHVzZWxlc3Mgd29yZHMuDQoNClRoZSBpbnRlbnRpb24gaXMg dG8gd2FybiBpbXBsZW1lbnRlcnMgdGhhdCB0aGUgSFRUUCBhbmQgb3RoZXIgZGF0YSByZWNlaXZl ZCB1bnRpbCB0aGUgdm91Y2hlciBjb250ZW50IGlzIHZlcmlmaWVkIGNvdWxkIGJlIGZyb20gYW4g YXR0YWNrZXIgc2luY2UgdGhlIFRMUyBjb25uZWN0aW9uIGlzIGluIGEgcHJvdmlzaW9uYWwgbW9k ZS4gUGVyaGFwcyB0aGlzIGlzIGNsZWFyZXI6ICANCg0KLSAgICAgICAgICAgIDx0PlRoZSBwbGVk Z2UgbWFpbnRhaW5zIGEgc2VjdXJpdHkgcGFyYW5vaWEgY29uY2VybmluZyB0aGUNCi0gICAgICAg ICAgICBwcm92aXNpb25hbCBzdGF0ZSwgYW5kIGFsbCBkYXRhIHJlY2VpdmVkLCB1bnRpbCBhIHZv dWNoZXIgaXMNCi0gICAgICAgICAgICByZWNlaXZlZCBhbmQgdmVyaWZpZWQgYXMgc3BlY2lmaWVk IGluIDx4cmVmDQotICAgICAgICAgICAgdGFyZ2V0PSJDb21wbGV0aW5nQXV0aGVudGljYXRpb25C b290c3RyYXBwaW5nIj48L3hyZWY+PC90Pg0KLQ0KKyAgICAgICAgICAgIDx0PlRoZSBwbGVkZ2Ug cGVyZm9ybXMgaW5wdXQgdmFsaWRhdGlvbiBvZiBhbGwgZGF0YSByZWNlaXZlZA0KKyAgICAgICAg ICAgICAgIHVudGlsIGEgdm91Y2hlciBpcyB2ZXJpZmllZCBhcyBzcGVjaWZpZWQgaW4gPHhyZWYN CisgICAgICAgICAgICAgICB0YXJnZXQ9IkNvbXBsZXRpbmdBdXRoZW50aWNhdGlvbkJvb3RzdHJh cHBpbmciPjwveHJlZj4gYW5kDQorICAgICAgICAgICAgICAgdGhlIFRMUyBjb25uZWN0aW9uIGxl YXZlcyB0aGUgcHJvdmlzaW9uYWwgc3RhdGUuIFVudGlsIHRoZXNlDQorICAgICAgICAgICAgICAg b3BlcmF0aW9ucyBhcmUgY29tcGxldGUgdGhlIHBsZWRnZSBjb3VsZCBiZSBjb21tdW5pY2F0aW5n DQorICAgICAgICAgICAgICAgd2l0aCBhbiBhdHRhY2tlci48L3Q+DQoNCg0KPj4gKDEwKSBTZWN0 aW9uIDUuMS4gIFBlciDigJxBIHBsZWRnZSB0aGF0IGNhbiBub3QgbWFpbnRhaW4gYXMgbWFueQ0K Pj4gY29ubmVjdGlvbnMgYXMgdGhlcmUgYXJlIGVsaWdpYmxlIHByb3hpZXMu4oCdLCB0aGlzIGlz IGFuIHVuZmluaXNoZWQNCj4+IHNlbnRlbmNlLiAgV2hhdCBzaG91bGQgdGhlIHBsZWRnZSBkbz8N Cj4gDQo+IGZpeGVkLg0KPiAgICAgICAgQSBwbGVkZ2UgdGhhdCBjYW4gbm90IG1haW50YWluIGFz IG1hbnkgY29ubmVjdGlvbnMgYXMgdGhlcmUgYXJlDQo+ICAgIC0gICBlbGlnaWJsZSBwcm94aWVz LiAgSWYgbm8gY29ubmVjdGlvbiBpcyBtYWtpbmcgcHJvZ2VzcyBhZnRlciA1IHNlY29uZHMNCj4g ICAgLSAgIHRoZW4gdGhlIHBsZWRnZSBTSE9VTEQgZHJvcCB0aGUgb2xkZXN0IGNvbm5lY3Rpb24g YW5kIGdvIG9uIHRvIGENCj4gICAgLSAgIGRpZmZlcmVudCBwcm94eTogdGhlIHByb3h5IHRoYXQg aGFzIGJlZW4gY29tbXVuaWNhdGVkIHdpdGggbGVhc3QNCj4gICAgLSAgIHJlY2VudGx5LiAgSWYg dGhlcmUgd2VyZSBubyBvdGhlciBwcm94aWVzIGRpc2NvdmVyZWQsIHRoZSBwbGVkZ2UgTUFZDQo+ ICAgIC0gICBjb250aW51ZSB0byB3YWl0LCBhcyBsb25nIGFzIGl0IGlzIGNvbmN1cnJlbnRseSBs aXN0ZW5pbmcgZm9yIG5ldw0KPiAgICAtICAgcHJveHkgYW5ub3VuY2VtZW50cy4NCj4gICAgKyAg IGVsaWdpYmxlIHByb3hpZXMgd2lsbCBuZWVkIHRvIHJvdGF0ZSBhbW9uZyB0aGUgdmFyaW91cyBj aG9pY2VzLA0KPiAgICArICAgdGVybWluYXRpbmcgY29ubmVjdGlvbnMgdGhhdCBkbyBub3QgYXBw ZWFyIHRvIGJlIG1ha2luZyBwcm9ncmVzcy4gIElmDQo+ICAgICsgICBubyBjb25uZWN0aW9uIGlz IG1ha2luZyBwcm9nZXNzIGFmdGVyIDUgc2Vjb25kcyB0aGVuIHRoZSBwbGVkZ2UNCj4gICAgKyAg IFNIT1VMRCBkcm9wIHRoZSBvbGRlc3QgY29ubmVjdGlvbiBhbmQgZ28gb24gdG8gYSBkaWZmZXJl bnQgcHJveHk6IHRoZQ0KPiAgICArICAgcHJveHkgdGhhdCBoYXMgYmVlbiBjb21tdW5pY2F0ZWQg d2l0aCBsZWFzdCByZWNlbnRseS4gIElmIHRoZXJlIHdlcmUNCj4gICAgKyAgIG5vIG90aGVyIHBy b3hpZXMgZGlzY292ZXJlZCwgdGhlIHBsZWRnZSBNQVkgY29udGludWUgdG8gd2FpdCwgYXMgbG9u Zw0KPiAgICArICAgYXMgaXQgaXMgY29uY3VycmVudGx5IGxpc3RlbmluZyBmb3IgbmV3IHByb3h5 IGFubm91bmNlbWVudHMuDQo+IA0KPj4gKDExKSBTZWN0aW9uIDUuMi4gIGNyZWF0ZWQtb24uICBU aGUgdmFsdWUgdG8gdXNlIGluIHRoaXMgZmllbGQgb2YgdGhpcw0KPj4gZmllbGQgaXMgbm90IGRl c2NyaWJlZCBoZXJlLg0KPiANCj4gLSAgICAgICAgICAgIFJFQ09NTUVOREVEIHRvIHBvcHVsYXRl IHRoaXMgZmllbGQuIFRoaXMgcHJvdmlkZXMgYWRkaXRpb25hbA0KPiAtICAgICAgICAgICAgaW5m b3JtYXRpb24gdG8gdGhlIE1BU0EuPC90Pg0KPiArICAgICAgICAgICAgUkVDT01NRU5ERUQgdG8g cG9wdWxhdGUgdGhpcyBmaWVsZCB3aXRoIHRoZSBjdXJyZW50IGRhdGUgYW5kDQo+ICsgICAgICAg ICAgICB0aW1lIGluIHlhbmc6ZGF0ZS1hbmQtdGltZSBmb3JtYXQuIFRoaXMgcHJvdmlkZXMgYWRk aXRpb25hbA0KPiAtICAgICAgICAgICAgaW5mb3JtYXRpb24gdG8gdGhlIE1BU0EuPC90Pg0KPiAN Cj4+ICgxMikgU2VjdGlvbiA1LjIuICBQZXIg4oCcQWxsIG90aGVyIGZpZWxkcyBNQVkgYmUgb21p dHRlZCBpbiB0aGUgcGxlZGdlDQo+PiB2b3VjaGVyLXJlcXVlc3TigJ0sIHNob3VsZCB0aGlzIGJl IHJlYWQgYXMgZ3VpZGFuY2UgdGhhdCB0aGUgZmllbGRzDQo+PiBtZW50aW9uZWQgYWJvdmUgdGhp cyB0ZXh0IGFyZSBtYW5kYXRvcnkgKGkuZS4sIGNyZWF0ZWQtb24sIG5vbmNlLA0KPj4gcHJveGlt aXR5LXJlZ2lzdHJhci1jZXJ0KS4gSWYgc28sIHdoYXQgdmFsdWUgc2hvdWxkIHBsZWRnZXMgd2l0 aG91dA0KPj4gY2xvY2tzIHVzZT8NCj4gDQo+IEkgZ3Vlc3M6DQo+ICAgICAgICAgICAgUGxlZGdl cyB0aGF0IGhhdmUgbm8gcmVhbC10aW1lIGNsb2NrcyBNQVkgb21pdCB0aGlzIGZpZWxkLg0KPiAN Cj4+ICgxMykgU2VjdGlvbiA1LjMuICBQZXIg4oCcSWYgdGhlc2UgdmFsaWRhdGlvbnMgZmFpbCB0 aGUgcmVnaXN0cmFyIFNIT1VMRA0KPj4gcmVzcG9uZA0KPj4gd2l0aCBhbiBhcHByb3ByaWF0ZSBI VFRQIGVycm9yIGNvZGXigJ0sIGEgZmV3IHF1ZXN0aW9uczoNCj4gDQo+IEhhLCBJIGtlcHQgYXNr aW5nIGZvciB1cyB0byBiZSBzcGVjaWZpYyBhYm91dCBlcnJvciBjb2RlcywgYnV0IEkgbWlzc2Vk IHRoaXMNCj4gcGFydC4NCj4gDQo+IC0gICAgICAgICAgSWYgdGhlc2UgdmFsaWRhdGlvbnMgZmFp bCB0aGUgcmVnaXN0cmFyIFNIT1VMRCByZXNwb25kIHdpdGggYW4NCj4gLSAgICAgICAgICBhcHBy b3ByaWF0ZSBIVFRQIGVycm9yIGNvZGUuDQo+ICsgICAgICAgICAgSWYgdGhlc2UgdmFsaWRhdGlv bnMgZmFpbCB0aGUgcmVnaXN0cmFyIFNIT1VMRCByZXNwb25kIHdpdGggdGhlDQo+ICsgICAgICAg ICAgSFRUUCA0MDQgZXJyb3IgY29kZS4gIElmIHRoZSB2b3VjaGVyLXJlcXVlc3QgaXMgaW4gYW4g dW5rbm93bg0KPiArICAgICAgICAgIGZvcm1hdCwgdGhlbiBhbiBIVFRQIDQwNiBlcnJvciBjb2Rl IGlzIG1vcmUgYXBwcm9wcmlhdGUuDQo+ICsgICAgICAgICAgQSBzaXR1YXRpb24gdGhhdCBjb3Vs ZCBiZSByZXNvbHZlZCB3aXRoIGFkbWluaXN0cmF0aXZlIGFjdGlvbg0KPiArICAgICAgICAgIChz dWNoIGFzIGFkZGluZyBhIHZlbmRvciB0byBhIHdoaXRlbGlzdCkgTUFZIGJlIHJlc3BvbmRlZCB3 aXRoIGFuDQo+ICsgICAgICAgICAgNDAzIEhUVFAgZXJyb3IgY29kZS4NCj4gDQo+IA0KPj4gKiog SXMgdGhpcyB0ZXh0IHN1Z2dlc3RpbmcgdGhhdCBzaWxlbnQgZmFpbHVyZT8gIEdpdmVuIHRoZSB0 ZXh0IHNheXMNCj4+IFNIT1VMRCwNCj4+IHZhbGlkYXRpb24gY291bGQgZmFpbCBhbmQgdGhlIHJl Z2lzdHJhciB3b3VsZCBub3Qgc2hhcmUgdGhpcyBmYWlsdXJlPw0KPj4gKiogV2hhdCBzcGVjaWZp YyBjb2RlcyBzaG91bGQgYmUgdXNlZD8NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0IHRoZXJlIG1heSBi ZSBvdGhlciBlcnJvciBjb2RlcyB0aGF0IHdvdWxkIG1ha2Ugc2Vuc2UsIHNvDQo+IEknbSBzdGlj a2luZyB3aXRoIFNIT1VMRC4NCj4gDQo+PiAoMTQpIFNlY3Rpb24gNS40LiAgUGVyIOKAnFRoZSBy ZWdpc3RyYXIgaW5pdGlhdGVzIHRoZSBjb25uZWN0aW9uIGFuZCB1c2VzDQo+PiB0aGUgTUFTQSBV Ukwgb2J0YWluZWQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi44IGZvciBbUkZDNjEyNV0NCj4+ IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBNQVNBLuKAnSwgUkZDNjEyNSBkb2VzbuKAmXQgaGF2ZSBh IFNlY3Rpb24gMi44Lg0KPj4gUGxlYXNlIGNsYXJpZnkgaG93IHRoaXMgY29ubmVjdGlvbiBpcyBt YWRlLg0KPiANCj4gYWhhLiBJdCdzIHNlY3Rpb24gMi44IG9mIHRoaXMgZG9jdW1lbnQhIFNvbWUg cHVuY3R1YXRpb24gaXMgbWlzc2luZy4NCj4gDQo+IC0gICAgICAgICAgPHhyZWYgdGFyZ2V0PSJv YnRhaW5tYXNhdXJsIiAvPiBmb3IgPHhyZWYgdGFyZ2V0PSJSRkM2MTI1IiAvPg0KPiAtICAgICAg ICAgIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBNQVNBLg0KPiArICAgICAgICAgIDx4cmVmIHRhcmdl dD0ib2J0YWlubWFzYXVybCIgLz4uIFRoZSBtZWNoYW5pc21zIGluDQo+ICsgICAgICAgICAgPHhy ZWYgdGFyZ2V0PSJSRkM2MTI1IiAvPiBTSE9VTEQgYmUgdXNlZCBhdXRoZW50aWNhdGlvbiBvZiB0 aGUNCj4gKyAgICAgICAgICBNQVNBLiAgU29tZSB2ZW5kb3JzIHdpbGwgZXN0YWJsaXNoIGV4cGxp Y2l0IChvciBwcml2YXRlKSB0cnVzdA0KPiArICAgICAgICAgIGFuY2hvcnMgZm9yIHZhbGlkYXRp bmcgdGhlaXIgTUFTQTsgdGhpcyB3aWxsIHR5cGljYWxseSBkb25lIGFzDQo+ICsgICAgICAgICAg cGFydCBvZiBhIHNhbGVzIGNoYW5uZWwgaW50ZWdyYXRpb24uICBSZWdpc3RhcnMgU0hPVUxEIHBl cm1pdA0KPiArICAgICAgICAgIHRydXN0IGFuY2hvcnMgdG8gYmUgcHJlLWNvbmZpZ3VyZWQgb24g YSBwZXItdmVuZG9yIGJhc2lzLg0KPiANCj4+ICgxNSkgU2VjdGlvbiA1LjUuICBXaGF0IGlzIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdmFsdWUgb2YgdGhlDQo+PiBjcmVhdGVkLW9uIGZp ZWxkIHBhc3NlZCBieSB0aGUgcGxlZGdlIHBlciBTZWN0aW9uIDUuMiwgYW5kIGRlc2NyaWJlZCBp bg0KPj4gU2VjdGlvbiA1LjUgYXMgYmVpbmcgcG9wdWxhdGVkIGJ5IHRoZSByZWdpc3RyYXIuDQo+ IA0KPiAtICAgICAgICA8dCBoYW5nVGV4dD0iY3JlYXRlZC1vbjoiPlJlZ2lzdHJhcnMgYXJlIFJF Q09NTUVOREVEIHRvIHBvcHVsYXRlDQo+ICAgICAgICAgdGhpcyBmaWVsZC4gVGhpcyBwcm92aWRl cyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHRoZSBNQVNBLjwvdD4NCj4gKyAgICAgICAgPHQg aGFuZ1RleHQ9ImNyZWF0ZWQtb246Ij4NCj4gKyAgICAgICAgICBUaGUgUmVnaXN0cmFycyBTSE9V TEQgcG9wdWxhdGUgdGhpcyBmaWVsZCB3aXRoIHRoZSBjdXJyZW50IGRhdGUgYW5kDQo+ICsgICAg ICAgICAgdGltZSB3aGVuIHRoZSBSZWdpc3RyYXIgZm9ybWVkIHRoaXMgdm91Y2hlciByZXF1ZXN0 LiBUaGlzIGZpZWxkDQo+ICsgICAgICAgICAgcHJvdmlkZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0byB0aGUgTUFTQS4NCj4gKyAgICAgICAgPC90Pg0KPiANCj4gDQo+PiAoMTYpIFNlY3Rpb24g NS41LiBXaGF0IGlzIGEg4oCcc3RhdGlzdGljYWxseSB1bmlxdWUgaWRlbnRpdHnigJ0gcGVyIHRo ZQ0KPj4g4oCcaWRldmlkLWlzc3VlcuKAnSBmaWVsZD8NCj4gDQo+IE1heD8NCj4gDQo+IEkgZG9u J3QgdGhpbmsgdGhlIHdvcmQgc3RhdGlzdGljYWxseSBpcyB1c2VmdWwgaGVyZS4NCg0KSXQgaXMg cG9zc2libHkgcGVkYW50aWMuIFRoZSB2b3VjaGVyIGxlYWYgb2YgaWRldmlkLWlzc3VlciAoc2Vl IFJGQzgzNjYpIGlzIHRoZSBBdXRob3JpdHkgS2V5IElkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiBS RkM1MjgwIGFuZCBJIHByb2JhYmx5IGhhdmUgaXQgaW4gbXkgaGVhZCB0aGF0IHRoaXMgaXMgb25s eSBzdGF0aXN0aWNhbGx5IHVuaXF1ZSB3aGVuIGl0cyBiYXNlZCBvbiB0aGUga2V5IGlkZW50aWZp ZXIgKHdoZXJlIHRoZSBrZXlzIGFyZSBvbmx5IHN0YXRpc3RpY2FsbHkgdW5pcXVlKS4gDQoNCi0g ICAgICAgIGlzIGluY2x1ZGVkIHRvIGVuc3VyZSBhIHN0YXRpc3RpY2FsbHkgdW5pcXVlIGlkZW50 aXR5LjwvdD4NCisgICAgICAgIGlzIGluY2x1ZGVkIHRvIGVuc3VyZSBhIHVuaXF1ZSBpZGVudGl0 eS48L3Q+DQoNCj4gVGhlIHNlcmlhbC1udW1iZXIgZXh0cmFjdGVkIGZyb20gdGhlIHBsZWRnZSBJ RGV2SUQgaXMgdW5pcXVlIHBlciBJRGV2SUQNCj4gaXNzdWVyLCBzbyB3ZSBpbmNsdWRlIHRoYXQg aGVyZS4gIEkgcmVhbGl6ZSB0aGF0IG15IGltcGxlbWVudGF0aW9uIGRvZXMNCj4gbm90IGluY2x1 ZGUgdGhpcyBhdCBhbGwsIGFuZCBJIGp1c3QgdXNlIHRoZSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZQ0K PiBwcmlvci1zaWduZWQtdm91Y2hlci1yZXF1ZXN0Lg0KPiANCj4+ICgxNykgU2VjdGlvbiA1Ljcu ICBQZXIgdGhlIEpTT04gc25pcHBldDoNCj4gDQo+PiAqKiBJdCBpc27igJl0IGxhYmVsZWQgYXMg YSBmaWd1cmUgb3IgZXhhbXBsZTsgYW5kIGlzbuKAmXQgcmVmZXJlbmNlZCBpbiB0aGUNCj4+IHRl eHQuDQo+IA0KPj4gKiogVGhpcyBpc27igJl0IHZhbGlkIEpTT046IG5vIGNvbW1hcyBiZXR3ZWVu IGl0ZW1zLiAgV2hhdCBkb2VzIHRoZQ0KPj4gbm90YXRpb24g4oCcLyoNCj4+IFRSVUU9U3VjY2Vz cywgRkFMU0U9RmFpbOKAneKAnSBtZWFuIOKAkyBvcGVuaW5nIHdpdGggYSAvKiBhbmQgY2xvc2lu ZyB3aXRoIGEg4oCcPw0KPiANCj4gZml4ZWQuDQo+IEkgbmVlZCB0byBnbyBiYWNrIHRocm91dGgg YW4gcmVudW1iZXIgdGhlIGZpZ3VyZXMgKG9yIHJhdGhlcix1c2UgYW5jaG9ycykuDQo+IA0KPj4g KDE4KSBTZWN0aW9uIDUuOC4yLiAgUGVyIOKAnEVhY2ggdGltZSB0aGUgTWFudWZhY3R1cmVyIEF1 dGhvcml6ZWQgU2lnbmluZw0KPj4gQXV0aG9yaXR5IChNQVNBKSBpc3N1ZXMgYSB2b3VjaGVyLCBp dCBwbGFjZXMgaXQgaW50byB0aGUgYXVkaXQgbG9nIGZvcg0KPj4gdGhhdCBkZXZpY2UuICBUaGUg ZGV0YWlscyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS44LuKAnSwgdGhpcw0KPj4gcmVmZXJl bmNlIHRvIFNlY3Rpb24gNS44IG9uIGhvdyB0aGUgTUFTQSBsb2dzIGRvZXNu4oCZdCBzZWVtIGNv cnJlY3QuDQo+PiBTZWN0aW9uIDUuOCBkZXNjcmliZXMgaG93IGENCj4+IHJlZ2lzdHJhciBhc2tz IGEgTUFTQSBhYm91dCBpdHMgbG9ncy4NCj4gDQo+ICAgICAgICAgICAgIEVhY2ggdGltZSB0aGUg TWFudWZhY3R1cmVyIEF1dGhvcml6ZWQgU2lnbmluZyBBdXRob3JpdHkgKE1BU0EpDQo+IC0gICAg ICAgICAgICBpc3N1ZXMgYSB2b3VjaGVyLCBpdCBwbGFjZXMgaXQgaW50byB0aGUgYXVkaXQgbG9n IGZvciB0aGF0IGRldmljZS4NCj4gLSAgICAgICAgICAgIFRoZSBkZXRhaWxzIGFyZSBkZXNjcmli ZWQgaW4gPHhyZWYgdGFyZ2V0PSJhdXRoekxvZ1JlcXVlc3QiIC8+Lg0KPiArICAgICAgICAgICAg aXNzdWVzIGEgdm91Y2hlciwgaXQgYXBwZW5kcyBkZXRhaWxzIG9mIHRoZSBhc3NpZ25tZW50IHRv DQo+ICsgICAgICAgICAgICBhbiBpbnRlcm5hbCBhdWRpdCBsb2cgZm9yIHRoYXQgZGV2aWNlLg0K PiArICAgICAgICAgICAgVGhlIGludGVybmFsIGF1ZGl0IGxvZyBpcyBwcm9jZXNzZWQgd2hlbiBy ZXNwb25kaW5nIHRvDQo+ICsgICAgICAgICAgICByZXF1ZXN0cyBmb3IgZGV0YWlscyBhcyBkZXNj cmliZWQgaW4gPHhyZWYNCj4gKyAgICAgICAgICAgIHRhcmdldD0iYXV0aHpMb2dSZXF1ZXN0IiAv Pi4NCj4gDQo+IERvZXMgdGhpcyB3b3JrIGZvciB5b3U/DQo+IEl0IGlzIG5vdCBvdXIgaW50ZW5k IHRvIHNwZWNpZnkgaG93IHRoZSBpbnRlcm5hbCBhdWRpdCBsb2cgd29ya3MsIGp1c3QNCj4gd2hh dCBpdCBtdXN0IGJlIGFibGUgdG8gcHJvZHVjZS4NCj4gDQo+PiAoMTkpIFNlY3Rpb24gNS45LjQu ICBXaGF0IGhhcHBlbnMgaWYgdGhlIHBsZWRnZSBkb2VzbuKAmXQgcmUtbmVnb3RpYXRlIGFuDQo+ PiBFU1QgVExTIHNlc3Npb24gYWZ0ZXIgYmVlbiBzdWNjZXNzZnVsIGVucm9sbGVkPw0KPiANCj4g SSdtIG5vdCBzdXJlLg0KPiBNYXg/DQoNCklmIHRoZSBjbGllbnQgc2tpcHMgcmVuZWdvdGlhdGlu ZyB0aGUgc2VydmVyIGRvZXMgbm90IGhhdmUgb3BlcmF0aW9uYWwgcHJvb2YgdGhhdCB0aGUgY2xp ZW50IGNhbiBzdWNjZXNzZnVsbHkgdXNlIHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIFRMUyBjbGllbnQg Y2VydGlmaWNhdGUuIEluc3RlYWQgaXQgd2lsbCBvbmx5IHJlY2VpdmUgdGhlIHRlbGVtZXRyeSBt ZXNzYWdlIHdoZXJlIHRoZSBjbGllbnQgY2xhaW1lZCBldmVyeXRoaW5nIGlzIOKAmVNVQ0VTU+KA mS4gDQpJIGRpZG7igJl0IHVzZSDigJhNVVNUJyBiZWNhdXNlIG9mIHRoZSBrZXl1c2FnZSBtb3Jh c3Mgd2hlcmUgcGVyaGFwcyB0aGUgY2VydCBpcyB0byBiZSB1c2VkIGZvciBzb21ldGhpbmcgd2hl cmUgVExTIGlzbuKAmXQgdmFsaWQuIEluIG90aGVyIGVucm9sbG1lbnQgcHJvdG9jb2wgZGlzY3Vz c2lvbnMgd2UgZWl0aGVyIG1ha2UgZXhjZXB0aW9ucyBmb3Ig4oCcbWlzdXNl4oCdIG9mIGEga2V5 IHR5cGUgZHVyaW5nIGVucm9sbG1lbnQgaXRzZWxmIChzdWNoIGFzIHBlcmZvcm1pbmcgYSBzaWdu aW5nIG9wZXJhdGlvbiB3aGVuIHRoZSBrZXkgdXNhZ2Ugc2F5cyBub3QgdG8pIG9yIGFjY2VwdCB0 aGF0IHRoZSBUTFMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1pZ2h0IGJlIHdpdGggYSBkaWZmZXJl bnQga2V5cGFpciB0aGFuIHRoZSBvbmUgZGlzdHJpYnV0ZWQgKHN1Y2ggYXMgdXNpbmcgRVNUIHRv IG1haW50YWluIGFuZCByZS1lbnJvbGwgYSBjZXJ0IHRoYXQgaXNu4oCZdCBhcHByb3ByaWF0ZSBm b3IgVExTKS4gVXNpbmcgIlNIT1VMROKAnSBoZXJlIGF2b2lkcyBoYXZpbmcgQlJTS0kgdGFrZSBh IHN0YW5jZSBvbiBhbnkgb2YgdGhvc2UgaXNzdWVzLiANCg0KLSBtYXgNCg0KPj4gKDIwKSBTZWN0 aW9uIDUuOS40LiAgSW4gd2hhdCB3YXkgaXMgYSB0aGUgU3ViamVjdEtleUlkZW50aWZpZXIgaW5j bHVkZWQNCj4+IGluIHRoZSBzdWNjZXNzIHRlbGVtZXRyeSBtZXNzYWdlPw0KPiANCj4gSWYgdGhl cmUgaXMgc3VjY2VzcywgSSBkb24ndCB0aGluayB0aGUgU3ViamVjdEtleUlkZW50aWZpZXIgbmVl ZHMgdG8gYmUNCj4gbG9nZ2VkLiAgSWYgdGhlcmUgaXMgZmFpbHVyZSwgdGhlbiB0aGUgaWRlYSB3 YXMgdGhhdCBpdCB3b3VsZCBnbyBpbnRvIHRoZQ0KPiByZWFzb24gaW4gc29tZSB0ZXh0dWFsIGZv cm0uDQo+IA0KPj4gKDIxKSBTZWN0aW9uIDYuICBXaGF0IGlzIOKAnC4uL3ZvdWNoZXJyZXF1ZXN0 4oCdPw0KPiANCj4gSXQncyBhIHR5cG8gZm9yIC9yZXF1ZXN0dm91Y2hlciENCj4gDQo+PiAoMjIp IFNlY3Rpb24gNy4gIFBlciDigJxUaGlzIHNlY3Rpb24gaXMgY29uc2lkZXJlZCBub24tbm9ybWF0 aXZlOiB1c2UNCj4+IHN1Z2dlc3RlZCBtZXRob2RzIE1VU1QgYmUgZGV0YWlsZWQgaW4gc3BlY2lm aWMgcHJvZmlsZXMgb2YgQlJTS0nigJ0gLS0NCj4+IHRoZSBjbGF1c2UgYWZ0ZXIgdGhlIGNvbG9u IGRvZXNu4oCZdCBwYXJzZS4gIFdoYXQgaXMgdGhlIGd1aWRhbmNlDQo+PiByZWxhdGl2ZSB0byBw cm9maWxlcz8NCj4gDQo+IEhvdyBhYm91dDoNCj4gICAgICAgIFRoaXMgc2VjdGlvbiBpcyBjb25z aWRlcmVkIG5vbi1ub3JtYXRpdmU6IHVzZSBvZiB0aGUgc3VnZ2VzdGVkDQo+ICAgICAgICBtZWNo YW5pc20gaGVyZSBNVVNUIGJlIGRldGFpbGVkIGluIHNwZWNpZmljIHByb2ZpbGVzIG9mDQo+ICAg ICAgICBCUlNLSS4gIFRoaXMgaXMgYSBzdWJqZWN0IGZvciBmdXR1cmUgd29yay4NCj4gDQo+IEkg ZG9uJ3QgdW5kZXJzdGFuZCAiV2hhdCBpcyB0aGUgZ3VpZGFuY2UgcmVsYXRpdmUgdG8gcHJvZmls ZXM/Ig0KPiANCj4+ICgyMykgU2VjdGlvbiAxMS4wLiAgVGhlIGNhdXRpb24gYWJvdXQgdW50cnVz dGVkIGRhdGEgYW5kIEhUVFAgbGlicmFyaWVzDQo+PiBzZWVtcyB3YXJyYW50ZWQuICBXb3VsZG7i gJl0IHRoaXMgYWxzbyBhcHBseSB0byB0aGUgYXBwbGljYXRpb24gY29kZSB0b28/DQo+IA0KPiBJ biB3aGF0IHdheSB0byBkbyB5b3UgbWVhbj8NCj4gTWF5YmUgdGhpcyBwYXJhZ3JhcGggaGFzIGJl ZW4gbWlzLXVuZGVyc3Rvb2QuDQo+IFdlIGFyZSB0cnlpbmcgdG8gc2F5IHRoYXQgZGVzcGl0ZSB0 aGUgaGVhZGVycyBhbmQgY29udGVudCBiZWluZyB1bnRydXN0ZWQsDQo+IHRoYXQgbWF0dXJlIEhU VFAgbGlicmFyaWVzIHNob3VsZCBub3QgYmUgcGFydGljdWxhcmx5IHZ1bG5lcmFibGUuICBJcw0K PiB0aGF0IHdoYXQgeW91IHVuZGVyc3Rvb2Q/DQo+IA0KPj4gKDI0KSBTZWN0aW9uIDExLjEuICBQ ZXIgdGhlIGxpc3Qgb2YgZXhhbXBsZXMgd2hlcmUgYSBNQVNBIGlzDQo+PiB1bmF2YWlsYWJsZSBv ciB1bmNvb3BlcmF0aXZlLCB3b3VsZG7igJl0IGEgbWFudWZhY3R1cmluZyBnb2luZyBvdXQgb2YN Cj4+IGJ1c2luZXNzIGFsc28gYmUgYSBjb25jZXJuPw0KPiANCj4gQWJzb2x1dGVseS4NCj4gT25l IHJlYXNvbiB3aHkgd2UgY2FsbCBpdCB0aGUgTWFudWZhY3R1cmVyICpBVVRIT1JJWkVEKiBzaWdu aW5nIGF1dGhvcml0eSwNCj4gaXMgdGhhdCB3ZSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBzb21ldGhp bmcgTWFudWZhY3R1cmVycyB3aWxsIG91dHNvdXJjZSwNCj4gYW5kIGJ1eWVycyB3aWxsIGluc2lz dCB0aGF0IHRoZXJlIGlzIGFuIGVzY3JvdyBwbGFuLg0KPiANCj4+ICgyNSkgU2VjdGlvbiBELjEu NC4gIFByb3ZpZGUgYW4gb3BlbnNzbCB2ZXJzaW9uIGFuZCByZWZlcmVuY2UgdGhhdA0KPj4gZ2Vu ZXJhdGVkIHRoaXMgb3V0cHV0DQo+IA0KPiBXZWxsLCBpdCB3YXMgZG9uZSB3aXRoIGxpYmNyeXB0 byAxLjEuMWMsIGZyb20gKG9wZW4gc291cmNlIHJ1YnkpIGNvZGUgbGlua2VkDQo+IGFnYWluc3Qg aXQuICBJIGNhbiBjZXJ0YWlubHkgc2F5IHRoYXQsIGJ1dCBJIGRvbid0IGtub3cgd2hhdA0KPiAi cmVmZXJlbmNlIiBtZWFucyBoZXJlLg0KPiANCj4+ICgyNikgUGVyIENocmlzdGlhbiBIdWl0ZW1h 4oCZcyBMYXN0IENhbGwgU2VjRGlyIFJldmlldw0KPj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3Jldmlldy1pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMjAtc2Vj ZGlyLWxjLWh1aXRlbWEtMjAxOS0wNi0wNC8pLA0KPj4gcGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxh c3QgdHdvIGlzc3VlcyDigJMgcmFuZG9tIG51bWJlciBnZW5lcmF0aW9uIGFuZCB0aGUNCj4+IG1p c3NpbmcgYXNzZXJ0aW9uIGxlYWYuDQo+IA0KPiBJIGhhZCBub3Qgc2VlbiB0aGlzIHNlY29uZCBy ZXZpZXcsIHRoYW5rIHlvdS4NCj4gSSB3aWxsIHJlYWQgdGhpcyBvbiBUaHVyc2RheSBhbmQgcG9z dCBhZGRpdGlvbmFsIGNoYW5nZXMuDQo+IA0KPiAtLQ0KPiBdICAgICAgICAgICAgICAgTmV2ZXIg dGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAgICAgICAgIHwgaXB2NiBtZXNoIG5ldHdvcmtzIFsN Cj4gXSAgIE1pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAg ICB8ICAgIElvVCBhcmNoaXRlY3QgICBbDQo+IF0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0dHA6 Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KPiANCj4g DQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4s IFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+ IA0KPiANCj4gDQoNCg== From nobody Wed Jul 10 21:37:10 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1E1200D7; Wed, 10 Jul 2019 21:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156281982750.15099.18057747928931811592.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 21:37:07 -0700 Archived-At: Subject: [Anima] Barry Leiba's No Objection on draft-ietf-anima-bootstrapping-keyinfra-22: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 04:37:08 -0000 Barry Leiba has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the comments that Warren makes in his ballot, and related comments in Alissa’s DISCUSS. While simple device provisioning and onboarding is critical, especially in IoT scenarios, I, too, have serious concerns about how such setups can allow too much control by vendors of the use that legitimate buyers can make of the products they bought. That said, I am balloting “no objectionâ€, because I don’t think that my opinion on that overrides the consensus of the working group and the IETF community, and we and other SDOs are working on alternative mechanisms to do similar things. From nobody Wed Jul 10 21:46:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A112009E; Wed, 10 Jul 2019 21:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0oD2givSmbVJ; Wed, 10 Jul 2019 21:46:34 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC27120048; Wed, 10 Jul 2019 21:46:34 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id i189so2124434pfg.10; Wed, 10 Jul 2019 21:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BTX6uLxpD1QtVTf5ikfm/aMb/1Ax1u1tgUtT69Pn4BE=; b=SImT4oQjiwS1oI2/4AIqmUIIaHhrJM7hsPs70AVJAtX42cFf1/90c7CXdSnxHIC9ya c5hnO73wDKbMQtKnTXxXdfPQ/uVHMcWOMz0sGN2KH4ezZuhKpD8h8nL4s4NqcwV/t0f0 275cHd36c9FDu0hMZShERaUklIU/73i7pLGcJLJXqbm4knqf5ET5w0eLho1oS3PU3rzS rE4J5zxzNgifvUHru3FMVJ5vmBP7JL1xvZh5ytVDi+h1i4yHJcXxAr6gYx8TXVyI/cDY hmBBfmuNm8ORifjq6LFxIJcqaVNmezLW9YxgQlZpBNdk6mg8PTEve6v67eUUF1XMKQE3 ZMaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BTX6uLxpD1QtVTf5ikfm/aMb/1Ax1u1tgUtT69Pn4BE=; b=n11mlsoh91HbaJcY0CCCkfl1iz/8q7krEcx7OQVFhNG7n2lNM8VxT3WfkiywnQCNqS ukujvlRXPh8wVWE6S767bAlUUNx8yrxtS/C5eBkrCoHCqVkLBuM7g4UcJ8ZzlcYiC9Ue hTcydaZtrlsElJTNeQA4l4jlLp4gK/suL7GFkL7XAYz5EntE76CoFvZ2+0QjrrVaK2pM L1gJCpUvFBnKbo1juvLFo30GLqEt7HvpOASvBKEsaLsT+m07gCVzIuMUAMIalfUW9VgX RP/WGX6I+Faxg9RKDwtlqZHgGsZwK1ev++XRqxZPH+yq/B5IUGMhVBxaDLIQvjITaeBa kyOA== X-Gm-Message-State: APjAAAXIpY4zH31vDt+X44sdAnu5lrZze1M1nVJ53FztWILx9vtgKJ0j NX5L2H3yo/ZGsm0zZviNaze42Oqk X-Google-Smtp-Source: APXvYqxYfRIlRvlOl/vPx6VzG0i2zNCnhcf9oyMVjiJzrJmDksRcTkl8WmpX+C/b/0qnDECYKPtGfw== X-Received: by 2002:a63:e907:: with SMTP id i7mr2228797pgh.84.1562820394009; Wed, 10 Jul 2019 21:46:34 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id e124sm6098427pfh.181.2019.07.10.21.46.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 21:46:33 -0700 (PDT) To: Michael Richardson , Alissa Cooper Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> <406.1562813786@localhost> From: Brian E Carpenter Message-ID: <5f70aa4e-4307-1445-33be-90bfeee79403@gmail.com> Date: Thu, 11 Jul 2019 16:46:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <406.1562813786@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 04:46:36 -0000 On 11-Jul-19 14:56, Michael Richardson wrote: > > Alissa Cooper via Datatracker wrote: > > I apologize if I'm misunderstanding how this works, but I didn't see much > > discussion in the document about the implications of the manufacturer going out > > of business. Specifically, it seems like if a device ships with BRSKI as its > > only available mechanism for bootstrapping and the manufacturer goes > > Section 7 provides some detail on a number of mechanisms that a manufacturer > could chose to include that would permit a device to be onboarded with > reduces levels of trust. > Section 7.2 specifically mentions onboarding via serial-console. > > (This situation is really no different from buying an iPhone 4 and then > complaining that you can't make it work because Apple won't give you > software that is secure, and since it's insecure, they won't onboard you, > except that you get a serial-console) Alissa, I've been concerned about this aspect since the -00 draft, especially for the case of air-gap deployments where the MASA is in any case inaccessible. I think it is indeed covered by section 7, which also mentions the need for future work. But it seems better to document the basic mechanism first. > > > = Section 1.3.1 = > > > "But this solution is not exclusive to large equipment: it is intended > > to scale to thousands of devices located in hostile environments, > > such as ISP provided CPE devices which are drop-shipped to the end > > user." > > > I don't quite understand how this squares with the scope limitation described > > in Section 1 and Section 9. If the whole network is professionally managed by > > the ISP, what part would be the "hostile environment"? > > The thousands of CPE devices (cable modems, VDSL modems, ISP provided home > routers) can be taken apart by the home owner. If such devices have IDevID > in a TPM module, then enrollment can be done securely. The same applies to equipment in street cabinets or shared premises, which might be physically accessible to bad actors (or untrustworthy employees). Brian From nobody Wed Jul 10 22:30:15 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 438B9120018; Wed, 10 Jul 2019 22:30:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 22:30:13 -0700 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 05:30:13 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) The text of the document suffers from lack of clarity throughout about whether the nonce-ful operation is mandatory or not, with several figures and discussions making declarative statements about nonce usage and others saying that nonce usage is optional. (See COMMENT.) (2) There also seems to be internal inconsistency about the proximity assertion process (and, any sort of assertion in a voucher-request at all, it seems). I've tried to note some locations in the Comment section. (3) There are other internal inconsistencies as well, including about section references for when various behaviors occur (see COMMENT). (4) In Section 5.6.1 The pledge MUST verify that the voucher nonce field is accurate and matches the nonce the pledge submitted to this registrar, or that the voucher is nonceless (see Section 7.2). Is the pledge supposed to accept a nonceless voucher in response to a nonce-ful voucher request? (5) RFC7951 is cited for the audit log response, but I cannot find the underlying YANG module that is JSON-encoded using the RFC 7951 procedures. Furthermore, I don't think the "nonce" handling (with explicit "NULL" string where base64-encoded binary data might be expected) would be consistent with the 7951 rules. (5) the new /enrollstatus EST endpoint seems under-specified. (6) In Section 7.2: The pledge can choose to accept vouchers using less secure methods. These methods enable offline and emergency (touch based) deployment use cases: 1. The pledge MUST accept nonceless vouchers. This allows for a use It's very unclear to me what this "MUST" means, especially so given that the entire section 7 is declared to be non-normative. Is it that the client "can choose" whether it "MUST accept nonceless vouchers"? That would seem to make the MUST basically ineffective. More broadly, if the entire Section 6 is non-normative, why is there any normative language in it? (7) the new /enrollstatus and /voucher_status well-known EST endpoints are not registered in Section 8.1 (7.1) I think we also need to register the "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. (8) The versioning mechanism for Pledge BRSKI Status Telemetry is underspecified, including the interaction with new registered values. (9) The versioning mechainsm for the MASA audit log response is underspecified, including whether a registry of field names is appropriate. (10) The term PKIX seems to be incorrectly used a few times; it refers to the Internet PKI, and so things like a private PKI internal to a manufacturer would probably not be best described as such. Such private PKIs can of course still reuse the protocols and mechanisms developed for PKIX, and it's accurate to describe them as such. (11) In a few places we describe the voucher-request in terms of its YANG structure but do not say that it has to be wrapped in a signed CMS object as is done for the RFC 8366 voucher. (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the domainID calculation? (13) In Section 5.5.1: As described in [RFC8366] vouchers are normally short lived to avoid revocation issues. If the request is for a previous (expired) voucher using the same registrar then the request for a renewed voucher SHOULD be automatically authorized. The MASA has sufficient I don't understand what "for a previous (expired) voucher" means. Is it something like "containing the same content as a previous voucher request for which a voucher was issued", with the presumption that the voucher expired before the pledge could successfully imprint, so it needs to try again? Or does this extend to longer timescales, like a device that gets deployed for a couple years and is then reset to factory settings and has to rebootstrap but is still by the same registrar? (14) In Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, the response data from the MASA MUST be a plaintext human- readable (ASCII, English) error message containing explanatory information describing why the request was rejected. It seems hard to support this stance on internationalization in 2019. (15) In Section 5.9.4: To indicate successful enrollment the client SHOULD re-negotiate the EST TLS session using the newly obtained credentials. This occurs by the client initiating a new TLS ClientHello message on the existing TLS connection. The client MAY simply close the old TLS session and start a new one. The server MUST support either model. Is this supposed to be sending a new TLS ClientHello in the application data channel or as a new handshake message (aka "renegotiation")? The latter is not possible in TLS 1.3 and is generally disrecommended anyways even in TLS 1.2. I would strongly suggest to remove the "renegotiation" option and just leave "close the connection and start a new connection/handshake". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [disclaimer: some of these comments get pretty blunt at the end; it's a long document and I'm tired. Please try not to get too annoyed if I'm failing to see something that's right in front of me.] I concur with the directorate reviewers that expected a high-level security analysis of what information flows where, and what policy choices can be made that affect it. At a *very* high level (skipping over a lot of things that I would expect to see), this would be structured like: On initial bootstrap, a new device uses local service autodiscovery to locate a (proxy to a) local registrar. Having found a candidate registrar, the fledgling pledge sends a fair bit of information about itself to the registrar, including its serial number and device identity (IDevID) along with a voucher request. The registrar can determine whether it expected such a device to appear, and locate a MASA, probably from an extension in the IDevID. Having determined that the MASA is suitable, the entire information from the initial voucher request (including device serial number) is transmitted over the internet in a TLS protected channel to the manufacturer, along with information about the registrar/owner. The manufacturer can then apply policy based onthe provided information and other sources of information, deciding whether to approve the claim by the registrar to own the device; if the claim is accepted, a voucher is issued that directs the device to accept its new owner. The voucher is returned to the registrar, but not necessarily to the device -- the registrar has an opportunity to examine the voucher, the MASA's audit logs, and other sources of information to determine whether the device has been tampered with, whether the bootstrap should be accepted, etc. No filtering of information is possible in the signed voucher, so this is a binary accept-or-not decision. If the registrar accepts the voucher as a proper one for its device, the voucher is returned to the pledge for imprinting. The voucher also includes a trust anchor that the pledge should use as representing the owner, successfully bootstrapping from an environment where only the manufacturer has some (limited) level of trust by the device into an environment where an owner has a PKI footprint on the device. When BRSKI is followed with EST this single footprint is further leveraged into the full owner's PKI and a LDevID for the device. Subsequent reporting steps provide flows of information to indicate success/failure of the process. I also concur with the directorate reviewer that wanted to see more discussion about the tradeoff in the applicability statement between manufacturer control and ease/automation of bootstrap Abstract (side note?) Is there a quick explanation of why bootstrapping can complete with just installation of the PKI (trust anchor?) and provisioning a locally issued certificate is not mandatory? Section 1 This document describes how pledges discover (or be discovered by) an element of the network domain to which the pledge belongs to perform the bootstrap. [...] nit: s/be/are/, IIUC. I think there's also something funky with the wording of "to perform the bootstrap"; we may be looking for an element "that will perform the bootstrap". 4. Pledge authorizing the registrar: "Should I join it?" nit: what is "it"? Surely not the registrar, and presumably the "network domain" in question? This document details protocols and messages to answer the above questions. It uses a TLS connection and an PKIX (X.509v3) certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer points 1 and 2. It uses a new artifact called a "voucher" that the I'm kind of confused by "[IDevID] LDevID", since my understanding was that the LDevID is issued only after all four steps are complete. Also, following the IDevID link lands me at a page that claims to be for a standard of status "superseded". nit: one can use X.509v3 without being PKIX, and it's not entirely clear that the IDevIDs will chain up to the Internet PKI. Section 1.2 RFC 8174 has an updated version of the BCP 14 boilerplate. I'd suggest adding "MASA Audit Log" as a defined term to give advance warning that this is an explicit protocol feature. domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT STRING of the subjectPublicKey of the pinned-domain-cert leaf, i.e. the Registrars' certificate. This is consistent with the subject key identifier (Section 4.2.1.2 [RFC5280]). What would it take to move away from SHA-1 for this purpose? It's unclear how long it will be before finding a second preimage of the SPKI hash is feasible and thus using it as an identifier no longer serves to uniquely identify something. enrollment: The process where a device presents key material to a network and acquires a network specific identity. For example nit: hyphenate "network-specific". Section 1.4 As a result of the protocol described herein, the bootstrapped devices have the Domain CA trust anchor in common. An end entity certificate has optionally been issued from the Domain CA. [...] This end-entity certificate is supposed "to authenticate each bootstrapped device to other parties in the domain", right? The major beneficiary is that it possible to use the credentials deployed by this protocol to secure the Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane]). I might humbly suggest "major intended beneficiary", as there seem to be many possibilities involving BRSKI. Section 1.5 The pledge must perform discovery of the proxy as described in Section 4.1 using GRASP M_FLOOD announcements. Is this DULL GRASP or full-on ACP GRASP flooding? Upon successfully validating a voucher artiface, a status telemetry MUST be returned. See Section 5.7. nit: artifact (right?) The ANI Join Registrar ASA MUST support all the BRSKI and above listed EST operations. nit: probably need to expand ASA the first time. Section 2 The text following Figure 1 suggests that the Domain Registrar is not always (also) a PKI RA, but the parentheticals in the figure itself are easy to read as a clarification and not an optional thing, especially since parentheticals are used in a different manner for the Key Infrastructure box. Section 2.1 3. Request to join the discovered registrar. A unique nonce is included ensuring that any responses can be associated with this particular bootstrapping attempt. But the nonce is not always present! 5. Enroll. After imprint an authenticated TLS (HTTPS) connection exists between pledge and registrar. Enrollment over Secure Transport (EST) [RFC7030] is then used to obtain a domain certificate from a registrar. Isn't this step optional? Section 2.2 A voucher is a cryptographically protected artifact (a digital signature) to the pledge device authorizing a zero-touch imprint on the registrar domain. nit: "using a digital signature" Vouchers provide a signed but non-encrypted communication channel among the pledge, the MASA, and the registrar. The registrar maintains control over the transport and policy decisions allowing the local security policy of the domain network to be enforced. nit: is there supposed to be a comma after "policy decisions" (in that both the transport and policy decisions allow for policy enforcement)? Section 2.3 Pledge authentication and pledge voucher-request signing is via a PKIX certificate installed during the manufacturing process. This is (As noted elsewhere, "PKIX" may not be the best term here.) 1. Uniquely identifying the pledge by the Distinguished Name (DN) and subjectAltName (SAN) parameters in the IDevID. The unique identification of a pledge in the voucher objects are derived from those parameters as described below. These unique identifiers can (by design) be used for tracking, so let's be sure that we talk about any privacy considerations with them, later. I see a mention in passing in Section 10.2, at least... 3. Secure auto-discovery of the pledge's MASA by the registrar (see Section 2.8). I don't think this is an ironclad property, since the crypto chain is slightly limited and you are in effect trusting the pledge to hand you something that says "use this issuer" but without as much crypto to back that up as we might want. We have to know that the given manufacturer that signed the IDevID actually is associated with the device we're trying to bootstrap, which can probably be arranged but I don't remember being called out explicitly. Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage extensions in the IDevID certificate. Any restrictions included I only got my hands on the 2018 rev of [IDevID], but that one does not actually talk about extendedKeyUsage. Section 2.3.1 In the context of BRSKI, pledges are uniquely identified by a "serial-number". This serial-number is used both in the "serial- number" field of voucher or voucher-requests (see Section 3) and in local policies on registrar or MASA (see Section 5). (editorial) if the IDevID is supposed to be a unique identifier, why do we need another one? o The subject field's DN encoding MUST include the "serialNumber" attribute with the device's unique serial number. (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes) side note: I had to think a bit to convince myself that DN is the right thing here; when we use dnsNames it's preferred to put them in subjectAltName to avoid having to pick a preferred/privileged one, but the serial number does seem to be in a privileged position for distinguishing the subject. o The subject-alt field's encoding MAY include a non-critical version of the RFC4108 defined HardwareModuleName. (from [IDevID] section 7.2.9) If the IDevID is stored in a Trusted Platform Module (TPM), then this field MAY contain the TPM identification rather than the device's serial number. If both fields are present, then the subject field takes precedence. "if both fields are present", but the subject field MUST be present, so this field can never take precedence. 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the Distinguished Name "serialNumber" attribute. [RFC4514] indicates this is a printable string so no encoding is necessary. I don't understand why these references were chosen. Why are LDAP specs authoritative about what the encoding format for the serialNumber DN attribute is? E.g., one could look at RFC 5280 to see that X520SerialNumber is a PrintableString. 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is base64 encoded to convert it to a printable string format. Please cite Section 4 of RFC 4648 (unless you mean base64url, in which case use Section 5). Also, it might be nice to somehow (maybe enumerate the first list in the same way) tie these two items to the respective subject ND/subjectAltName fields, to clarify why these are the only two choices. As explained in Section 5.5 the Registrar MUST extract the serial- number again itself from the pledge's TLS certificate. [...] To be clear, this is still the device's IDevID certificate, that just happens to be getting used as a TLS client certificate. Section 2.3.2 nit: maybe put a blank line after the IMPORTS are over? Section 2.4 In Figure 3, I had to think a bit to figure out whether the text that did not fit mid-arrow was supposed to apply to the arrow above or below the text (e.g., "optional: mDNS query RFC6763/RFC6762"). [Hmm, so we send our TLS client cert on the provisional connection, meaning that we have to trust the proxy and registrar to be doing the right thing w.r.t. broadcasting our identity to the world] Section 2.5.1 The pledge is the device that is attempting to join. Until the pledge completes the enrollment process, it has link-local network connectivity only to the proxy. nit(?): I think there is a subtle difference in meaning between "only has link-local network connectivity to the proxy" and this text, and I'm not sure which is intended. Section 2.5.3 This may just be my personal preference (so feel free to ignore), but talking about a "trust store used to authenticate the MASA" and "trust store used to authenticate the pledge" would feel more readable than "trust anchor database for authenticating the [thing] TLS connection [thing] certificate". It may be worth some comment about how this requirement for out-of-band distribution of implicit trust anchors is something that BRSKI is designed to avoid, but that distributing to just the registrar is a much more manageable task than distributing them to all devices/pledges. Section 2.5.5 The Public Key Infrastructure (PKI) administers certificates for the domain of concerns, providing the trust anchor(s) for it and allowing nit: "domain of concern" singular The voucher provides a method for the distribution of a single PKI trust anchor (as the "pinned-domain-cert"). A distribution of the Earlier we talked about the "pinned-domain-cert leaf" in the domainID definition. Was that supposed to be "leaf" in the YANG sense and not in the PKIX "leaf certificate"/"end-entity certificate" sense? The expectations of the PKI are unchanged from EST [[RFC7030]]. This Which parts of RFC 7030 talk about its expectations of the PKI? Section 2.6.1 Many devices when bootstrapping do not have knowledge of the current time. Mechanisms such as Network Time Protocols cannot be secured until bootstrapping is complete. Therefore bootstrapping is defined in a method that does not require knowledge of the current time. A nit: I'd suggest maybe "framework", "scenario", or "environment" rather than "method". Section 2.6.2 [RFC5280] explains that long lived pledge certificates "SHOULD be assigned the GeneralizedTime value of 99991231235959Z". Registrars This misses the important "for the notAfter field" part. Why is 3 years the relevant cutoff here? Section 2.7 There exist operationally open network wherein devices gain nit: "networks" plural unauthenticated access to the internet at large. In these use cases the management domain for the device needs to be discovered within the larger internet. These are less likely within the anima scope but may be more important in the future. nit: less likely than what? There are additionally some greenfield situations involving an entirely new installation where a device may have some kind of management uplink that it can use (such as via 3G network for instance). In such a future situation, the device might use this management interface to learn that it should configure itself to become the local registrar. In order to support these scenarios, the pledge MAY contact a well known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar. I don't see the connection between "configure itself to become the local registrar" and "contact a well-known URI of a cloud registrar". If the pledge uses a well known URI for contacting a cloud registrar an Implicit Trust Anchor database (see [RFC7030]) MUST be used to authenticate service as described in [RFC6125]. This is consistent Would this be more likely to be installed by the manufacturer or device owner? nit: "service" needs an article. Section 2.8 approach if they ensure a single MASA URL works for all pledge's associated with each trust anchor. nit: "pledges" non-possessive Section 3 A pledge forms the "pledge voucher-request" and submits it to the registrar. It would be helpful (at least to me) to know that the request is signed by the IDevID cert, here. The "proximity-registrar-cert" leaf is used in the pledge voucher- requests. This provides a method for the pledge to assert the registrar's proximity. "proximity" in what sense? How much verification/confidence needs to be done? (Also, I would have expected the assertion to go the other way; that the registrar asserts the pledge's proximity -- how does the pledge have a way to know that the registrar is nearby when the proxy is transparent?) Section 3.3 Example (1) The following example illustrates a pledge voucher- request. The assertion leaf is indicated as 'proximity' and the registrar's TLS server certificate is included in the 'proximity-registrar-cert' leaf. See Section 5.2. { "ietf-voucher-request:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "created-on": "2017-01-01T00:00:00.000Z", "proximity-registrar-cert": "base64encodedvalue==" } } I do not see an 'assertion' leaf populated. Example (2) The following example illustrates a registrar voucher- request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example). The pledge's voucher-request is a binary object. In the JSON encoding used here it must Why is it a binary object? We just saw a previous example with a JSON (non-binary) encoding. (Hint: CMS-signed,but we didn't say that.) be base64 encoded. The nonce, created-on and assertion is carried forward. The serial-number is extracted from There is (again) no assertion, and the created-on does not match exactly. Section 3.4 The RFC 8174 version of the BCP 14 boilerplate could be used in the module, too. Also, is the 2017 copyright still correct, especially given that it is a 2018-02-14 revision? For example, a pledge might sign a voucher request with a proximity-registrar-cert, and the registrar then includes it in the prior-signed-voucher-request field. nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)? This is a simple mechanism for a chain of trusted parties to change a voucher request, while maintaining the prior signature information. "chain" seems to admit the possibility of more than one modification/resigning event, but the architecture as described seems to only have the registrar doing this. registrar agree on proximity assertions. The MASA SHOULD remove all prior-signed-voucher-request information when signing a voucher for imprinting so as to minimize the final voucher size."; (side note?) This removal would open up some minor exotic attacks in cases where a pledge reuses an existing nonce (potentially from a different device), but is probably an okay tradeoff to make. The first certificate in the Registrar TLS server certificate_list sequence (see [RFC5246]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request if a proximity assertion is requested."; 5246 is replaced by 8446. It might be simplest to just say the "end-entity TLS certificate", at least for TLS practitioners. (Maybe nof for a different audience, though.) How do I know that a proximity assertion is requested? Section 4 The role of the proxy is to facilitate communications. The proxy forwards packets between the pledge and a registrar that has been provisioned to the proxy via GRASP discovery. [same DULL question as above] The proxy does not terminate the TLS handshake: it passes streams of bytes onward without examination. A proxy MUST NOT assume any specific TLS version. Passing bytes without examination is by definition not assuming any version of TLS. So while I think it would make the most sense to just remove that sentence, if it's going to say it might be worth also noting the TLS invariants discussed in https://tools.ietf.org/html/rfc8446#section-9.3 . Section 4.1 through a proxy. The proxy is transparent to the pledge. The communication between the pledge is over IPv6 Link-Local addresses. nit: between the pledge and what? M_FLOOD. The active methods SHOULD exponentially back-off to a maximum of one hour to avoid overloading the network with discovery attempts. Detection of change of physical link status (ethernet carrier for instance) SHOULD reset the exponential back off. Mathematically, "exponential" requires to specify the base of the exponent (or just say "by doubling"). (Also later in the section.) Once all discovered services are attempted (assuming that none succeeded) the device MUST return to listening for GRASP M_FLOOD. It SHOULD periodically retry the manufacturer specific mechanisms. The pledge MAY prioritize selection order as appropriate for the anticipated environment. nit: "manufacturer-specific" takes a hyphen not-nit: what are "the manufacturer-specific mechanisms"? (I don't remember such discussion yet.) Once all discovered services are attempted (assuming that none succeeded) the device MUST return to listening for GRASP M_FLOOD. It SHOULD periodically retry the manufacturer specific mechanisms. The pledge MAY prioritize selection order as appropriate for the anticipated environment. nit: "manufacturer-specific" takes a hyphen not-nit: what are "the manufacturer-specific mechanisms"? (I don't remember such discussion yet.) Section 4.1.1 Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or some other notation? Also, I'm not sure that picking an arbitrary (representative) session-id value, LL address, and port is helpful when describing the formatting of the message. Maybe some different introductory text would change things. Section 4.3 If we're only defining an EST-TLS objective, how will proxies know that the registrar supports BRSKI? It's a little weird to put the reference for GRASP but not ACP. Either none or both would feel more natural (given that we've seen both already a couple times). Section 5 MASA URI is "https://" iauthority "/.well-known/est". nit: "The MASA URI". Is this always the case, with no opportunity for modification, even as included in an IDevID certificate extension? BRSKI uses JSON [RFC7159] for all new operations defined here, and RFC 7159 is obsoleted by RFC 8259. While EST section 3.2 does not insist upon use of HTTP 1.1 persistent connections, BRSKI-EST connections SHOULD use persistent connections. The intention of this guidance is to ensure the provisional TLS state occurs only once, and that the subsequent resolution of the provision state is not subject to a MITM attack during a critical phase. I think we probably want a requirement that if persistent connections are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST check that the exact same certificate is used to authenticate the registrar for all transactions. If the signature in the handshake is valid but you can only chain the certificate up to your trust anchor once you finish imprinting, you still know that the entire session's data has been talking to the now-authenticated party (as opposed to the TLS case where you try to add a new certificate mid-connection, where that boundary is unclear), but things are much easier to reason about if you are sure that each EST transaction is talking to the same peer. o In the language of [RFC6125] this provides for a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. The SERIALNUM-ID whitelist is collated according to manufacturer trust anchor since serial numbers are not globally unique. RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in the model of RFC 6125" or "provides a new SERIAL-ID category" or similar. o The registrar performs log verifications in addition to local authorization checks before accepting optional pledge device enrollment requests. Maybe give us a section reference to what the "log validations" are? Section 5.1 Establishment of the BRSKI-EST TLS connection is as specified in EST [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] wherein the client is authenticated with the IDevID certificate, and the EST server (the registrar) is provisionally authenticated with an unverified server certificate. I'd consider noting that the signature (or other operation) made by the certificate must be validated, and that the received certificate and chain must be retained for later validation. The pledge maintains a security paranoia concerning the provisional state, and all data received, until a voucher is received and verified as specified in Section 5.6.1 Since section 5.6.1 just talks about the voucher verification process, I think we need to say more about what "security paranoia" entails: acknowledging that all data transmitted is sent to an unauthenticated peer, with corresponding privacy considerations, and that all received data is not authenticated by the TLS connection and must be self-authenticating or otherwise considered untrusted. A pledge that can not maintain as many connections as there are eligible proxies. If no connection is making process after 5 seconds nit: that's not a complete sentence. Section 5.2 application/voucher-cms+json The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in Section 3 using the JSON encoding described in [RFC7951]. This Section 3 does not describe any "sign[ing] using a CMS structure" operation. voucher media type is defined in [RFC8366] and is also used for the pledge voucher-request. The pledge SHOULD sign the request using the Section 2.3 credential. To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other credential) to sign? constrained voucher formats are expected in the future. Registrar's and MASA's are expected to be flexible in what they accept. nits: no apostrophes for plurals. proximity-registrar-cert: In a pledge voucher-request this is the first certificate in the TLS server 'certificate_list' sequence (see [RFC5246]) presented by the registrar to the pledge. This MUST be populated in a pledge voucher-request if the "proximity" assertion is populated. [same comment as above about "end-entity certificate"] The registrar validates the client identity as described in EST [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' assertion and associated 'proximity-registrar-cert' are correct. what 'proximity' assertion? Does verifying proximity-registrar-cert just mean checking that it's the same leaf certificate that the registrar presented? What happens if the validation fails? Section 5.3 A Registrar accepts or declines a request to join the domain, based on the authenticated identity presented. Automated acceptance criteria include: I suggest "for different networks, examples of automated acceptance criteria may include". If these validations fail the registrar SHOULD respond with an appropriate HTTP error code. Similarly, "If validation fails". Section 5.4 The BRSKI-MASA TLS connection is a 'normal' TLS connection appropriate for HTTPS REST interfaces. The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8 for [RFC6125] authentication of the MASA. I'd consider mentioning the implicit trust anchor database as well as the MASA URL. The MASA and the registrars SHOULD be prepared to support TLS client certificate authentication and/or HTTP Basic or Digest authentication as described in [RFC7030] for EST clients. This connection MAY also have no client authentication at all (Section 7.4) I don't see discussion of skipping client authentication in Section 7.4. It would be great to have some, there! The authentication of the BRSKI-MASA connection does not affect the voucher-request process, as voucher-requests are already signed by the registrar. Instead, this authentication provides access control to the audit log. I don't understand what "access control to the audit log" means. Is the idea that the TLS client identity in the BSRKI-MASA connection is only used when processing requests to the requestauditlog endpoint and that some clients might be denied access? Section 5.5 created-on: Registrars are RECOMMENDED to populate this field. This provides additional information to the MASA. Earlier we said that this field would be propagated from the pledge voucher-request; we should probably say something like "populate this field; if it was present in the pledge voucher-request it is copied unchanged to the registrar voucher-request; otherwise the current time is used". nonce: This is the value from the pledge voucher-request. The registrar voucher-request MAY omit the nonce as per Section 3.1) I'd suggest "value from the pledge voucher-request, if present" and changing the second sentence to refer to the pledge voucher-request. idevid-issuer: The idevid-issuer value from the pledge certificate is included to ensure a statistically unique identity. There is no "idevid-issuer" field in the pledge certificate; I assume this is supposed to be the Issuer Name of the IDevID certificate. prior-signed-voucher-request: The signed pledge voucher-request SHOULD be included in the registrar voucher-request. (NOTE: what is included is the complete pledge voucher-request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This is a good example of text that implies the signed voucher is binary. (And as such would be a good place to talk about the base64 encoding.) All other fields MAY be omitted in the registrar voucher-request. Should the proximity-registrar-cert field *not* be present? Section 5.5.2 The MASA MUST verify that the registrar voucher-request is signed by a registrar. This is confirmed by verifying that the id-kp-cmcRA extended key usage extension field (as detailed in EST RFC7030 section 3.6.1) exists in the certificate of the entity that signed the registrar voucher-request. This verification is only a consistency check that the unauthenticated domain CA intended the voucher-request signer to be a registrar. Performing this check provides value to the domain PKI by assuring the domain administrator that the MASA service will only respect claims from authorized Registration Authorities of the domain. If the MASA has no prior knowledge of the domain (certificate), this is susceptible to anyone spinning up something that claims to be a domain CA and issuing registrar certs with that extension. We need to document somewhere what other part of the system prevents that from causing an unauthorized voucher to be used. (Perhaps preventing one from being issued is not feasible, but acceptable if the pledge will not accept it, though there remains risk of DoS on the MASA.) Section 5.5.3 If a nonceless voucher-request is submitted the MASA MUST authenticate the registrar as described in either EST [RFC7030] section 3.2, section 3.3, or by validating the registrar's Subsubsection references might be more helpful. In the nonced case, validation of the registrar MAY be omitted if the device policy is to accept audit-only vouchers. I don't see any (SHOULD?) guidance about validating the registrar in the nonced case when other policy is used. Even the previous section does not really say much to indicate there is value in authenticating the signature on the voucher request. Section 5.5.4 authentication or voucher-request signature validation. Similarly, as noted in Section 5.5.2, the MASA performs normal PKIX revocation checking during signature consistency checks (a signature by a registrar certificate that has been revoked is an inconsistency). I think this needs to be noted more clearly in Section 5.5.2. Section 5.5.5 The MASA MAY verify that the registrar voucher-request includes the 'prior-signed-voucher-request' field. If so the prior-signed- voucher-request MUST include a 'proximity-registrar-cert' that is consistent with the certificate used to sign the registrar voucher- request. Additionally the voucher-request serial-number leaf MUST This seems kind of tautological ("if the MASA is checking X, X MUST have happened"). Also, what does "consistent with" mean? match the pledge serial-number that the MASA extracts from the signing certificate of the prior-signed-voucher-request. The MASA is aware of which pledges support signing of their voucher requests and can use this information to confirm proximity of the pledge with the registrar, thus ensuring that the BRSKI-EST TLS connection has no man-in-the-middle. To be clear, this MITM detection is only for the case of pledges that sign their voucher requests, right? And it seems to only hold if pledges that support signing actually do sign, every time. Section 5.5.6 The registrar's certificate chain is extracted from the signature method. The chain includes the domain CA certificate as specified in Section 5.5. This certificate is used to populate the "pinned- I don't think Section 5.5 is the right reference for "includes the domain CA certificate" (both here and in 5.5.2). domain-cert" of the voucher being issued. The domainID (e.g., hash of the root public key) is determined from the pinned-domain-cert and is used to update the audit log. If the pinning takes the whole cert (per RFC 8366), then what do we need the domainID for? Just the audit log? Surely in that case SHA-1 is not a hard requirement... Section 5.5.7 The MASA MUST use the nonce from the registrar voucher-request for the resulting voucher and audit log. The prior-signed-voucher- request nonce is ignored during this operation. I don't understand this requirement. They could only be different if the MUST from the previous paragraph is ignored. Section 5.6 The MASA voucher response to the registrar is forwarded without changes to the pledge; therefore this section applies to both the MASA and the registrar. The HTTP signaling described applies to both the MASA and registrar responses. A registrar either caches prior MASA responses or dynamically requests a new voucher based on local policy (it does not generate or sign a voucher). [...] Do we need to say how this local caching policy interacts with HTTP cache control headers? I got confused by "or dynamically requests a new voucher" the first couple times I read it; I landed on something like "when a voucher request arrives at the registrar, if it has a cached response from the MASA for the corresponding registrar voucher-request, that cached response can be used according to local policy; otherwise the registrar constructs a new registrar voucher-request and sends it to the MASA". type. The registrar SHOULD use this response if it determines the pledge is unacceptable due to inventory control, MASA audit logs, or any other reason. What does "unacceptable due to inventory control" mean? A 415 (Unsupported Media Type) response is approriate for a request that has a voucher-request or accept encoding that is not understood. Isn't "Accept-Encoding:" a more typical spelling? vouchers are described in detail in [RFC8366]. For example, the voucher consists of: { "ietf-voucher:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "assertion": "logging" "pinned-domain-cert": "base64encodedvalue==" "serial-number": "JADA123456789" } } nit: I think "might consist of" is better than "consists of". assertion: The method used to verify assertion. See Section 5.5.5. The method used to verify itself? The pledge MUST be prepared to parse and fail gracefully from a voucher response that does not contain a 'pinned-domain-cert' field. What would such a graceful failure look like? Reverting back to the discovery stage, since without a manufacturer-validated indication of the trust anchor for the domain, the pledge cannot consider itself to be a part of a domain? Section 5.6.2 found. It SHOULD return to the same proxy again after attempting with other proxies. Attempts should be attempted in the exponential But only if those other proxies failed to produce a valid voucher? The pledge's PKIX path validation of a registrar certificate's validity period information is as described in Section 2.6.1. Once the PKIX path validation is successful the TLS connection is no longer provisional. Section 2.6.1 doesn't actually say that the pledge has to check the five listed timestamps in the case that it does have a realtime clock. Section 5.7 To indicate pledge status regarding the voucher, the pledge MUST post a status message. I think we've had other text that implies that providing telemetry is optional; perhaps just "the pledge POSTs a status message"? The client HTTP POSTs the following to the server at the EST well known URI "/voucher_status". The Status field indicates if the I think it's probably more clear to write out ".well-known/est/voucher_status"; there's not a separate registry of EST well-known URIs. We don't actually have anything in this section that declares "this is the structure of the JSON object used as the POST body"; it's only implicitly provided. indicates why. In the failure case this message may be sent to an unauthenticated, potentially malicious registrar and therefore the Reason string SHOULD NOT provide information beneficial to an attacker. The operational benefit of this telemetry information is What sort of information might a pledge consider including that would be beneficial to an attacker? { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail" I guess you should probably close the comment, not that this is a formal comment syntax for JSON... The reason-context attribute is an arbitrary JSON object (literal value or hash of values) which provides additional information specific to this pledge. The contents of this field are not subject to standardization. This still have some privacy considerations, though. Section 5.8 is posted to the /requestauditlog URI instead. The "idevid-issuer" and "serial-number" informs the MASA which log is requested so the appropriate log can be prepared for the response. Using the same Is the implicit point that the other fields are ignored? A registrar MAY request logs at future times. If the registrar generates a new request then the MASA is forced to perform the additional cryptographic operations to verify the new request. Is this statement just supposed to be further justification for using the original voucher-request as the POST body, or describing new behavior? A MASA that receives a request for a device that does not exist, or for which the requesting owner was never an owner returns an HTTP 404 ("Not found") code. What is a "requesting owner"? I thought devices were owned by the domain, not the specific registrar. In order to avoid enumeration of device audit logs, MASA that return URLs SHOULD take care to make the returned URL unguessable. For instance, rather than returning URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD return a randomly generated value (a "slug" in web parlance). The value is used to find the relevant database entry. https://www.w3.org/TR/capability-urls/ may also be a useful reference. Section 5.8.1 A log data file is returned consisting of all log entries associated with the the device selected by the IDevID presented in the request. The audit log may be truncated of old or repeated values as explained below. The returned data is in JSON format ([RFC7951]), and the Content-Type SHOULD be "application/json". For example: If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". This document specifies a simple log format as provided by the MASA service to the registrar. This format could be improved by distributed consensus technologies that integrate vouchers with technologies such as block-chain or hash trees or optimized logging approaches. Doing so is out of the scope of this document but is an anticipated improvement for future work. As such, the registrar client SHOULD anticipate new kinds of responses, and SHOULD provide operator controls to indicate how to process unknown responses. This would be a great place to talk about the "version" field that's otherwise ignored. anticipated improvement for future work. As such, the registrar client SHOULD anticipate new kinds of responses, and SHOULD provide operator controls to indicate how to process unknown responses. Is "registrar client" intended to be both words or just one? A registrar SHOULD use the log information to make an informed decision regarding the continued bootstrapping of the pledge. The I may be confused, but I thought the registrar was asking for the log after the voucher had already been issued. Are these check supposed to keep the registrar from forwarding the voucher to the pledge, or just as a check for future renewal operations? A relatively simple policy is to white list known (internal or external) domainIDs and to require all vouchers to have a nonce and/ or require that all nonceless vouchers be from a subset (e.g. only internal) domainIDs. A simple action is to revoke any locally issued nit: missing "of" credentials for the pledge in question or to refuse to forward the voucher. A registrar MAY be configured to ignore the history of the "simple action" in the case that the registrar doesn't like the audit log results? device but it is RECOMMENDED that this only be configured if hardware assisted NEA [RFC5209] is supported. Probably need to expand NEA. Section 5.9 Although EST allows clients to obtain multiple certificates by sending multiple CSR requests BRSKI mandates use of the CSR Attributes request and mandates that the registrar validate the CSR against the expected attributes. This implies that client requests Where is this requirement stated normatively? Section 5.9.1 This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert (see Section 5.6.1 for a discussion of the limitations inherent in having a single certificate instead of a full CA Certificates response.) Although these I don't see such a discussion in the indicated section. Section 5.9.2 To alleviate these operational difficulties, the pledge MUST request the EST "CSR Attributes" from the EST server and the EST server needs to be able to reply with the attributes necessary for use of the certificate in its intended protocols/services. This approach allows "intended" implies that the EST server has some knowledge of what the pledge is expected to be doing in the network, right? To alleviate these operational difficulties, the pledge MUST request the EST "CSR Attributes" from the EST server and the EST server needs to be able to reply with the attributes necessary for use of the certificate in its intended protocols/services. This approach allows for minimal CA integrations and instead the local infrastructure (EST server) informs the pledge of the proper fields to include in the generated CSR. This approach is beneficial to automated boostrapping in the widest number of environments. This is convenient, but has some security considerations in that it implies that the validation policy on the CA is somewhat lax, since the EST server is expected to be doing most of the policy controls. Thus, a compromised pledge/device could send a CSR with unauthorized fields and it is likely to be signed, allowing for some level of privilege escalation. When the registrar acts as a proxy to the CA as well as its EST role, as described later, this risk is diminished. In networks using the BRSKI enrolled certificate to authenticate the ACP (Autonomic Control Plane), the EST attributes MUST include the "ACP information" field. See [I-D.ietf-anima-autonomic-control-plane] for more details. This MUST seems like it belongs in the ACP spec and need not be repeated here using normative language. Section 5.9.4 administrators concerning device lifecycle status. This might include information concerning attempted bootstrapping messages seen by the client, MASA provides logs and status of credential enrollment. [RFC7030] assumes an end user and therefore does not This looks like a comma splice. In the case of a FAIL, the Reason string indicates why the most recent enrollment failed. The SubjectKeyIdentifier field MUST be included if the enrollment attempt was for a keypair that is locally We haven't talked about POSTing to a new status-report endpoing yet, so this comes out of the blue. It would probably be worth adding above "SHOULD [start a new TLS handshake] and POST a enrollment status message". "Status":TRUE /* TRUE=Success, FALSE=Fail" [same note about JSON comments] "reason-context": "Additional information" Is this supposed to be a string or a JSON object similar to /voucher_status? This allows for clients that wish to minimize their crypto operations to simply POST this response without renegotiating the TLS session - at the cost of the server not being able to accurately verify that enrollment was truly successful. I'd prefer to not have this sort of option available, but I can't disprove the claim of its utility, so I will not object if it stays. Section 5.9.5 Is the idea that the initial BRSKI-EST-issued certificate would authenticate the client for the subsequent EST requests? Section 7 If this is non-normative and will need to be fleshed out in a separate document, would an Appendix be more appropriate? Section 7.1 Pledge: The pledge could be compromised and providing an attack vector for malware. The entity is trusted to only imprint using secure methods described in this document. Additional endpoint How do "could be compromised" and "is trusted to only [...]" go together? Vendor Service, MASA: This form of manufacturer service is trusted to accurately log all claim attempts and to provide authoritative log information to registrars. The MASA does not know which devices are associated with which domains. These claims could be I think this is maybe more of a "does not enforce" than "does not know", since the domainID ends up in the audit logs that the MASA holds. Current text provides only for a trusted manufacturer. nit: not a complete sentence. Section 7.3 A registrar can choose to accept devices using less secure methods. These methods are acceptable when low security models are needed, as the security decisions are being made by the local administrator, but they MUST NOT be the default behavior: I'm having a hard time parsing "low security models"; the best I can come up with is "threat models where low security is adequate". Lower security modes chosen by the MASA service affect all device deployments unless bound to the specific device identities. In which Is this "unless the lower-security behavior is tied to specific device identities"? case these modes can be provided as additional features for specific customers. The MASA service can choose to run in less secure modes nit: This middle sentence is not a complete sentence. 1. Not enforcing that a nonce is in the voucher. This results in distribution of a voucher that never expires and in effect makes A nonceless voucher can still include an expiration time ... it is just in practice possible for it to never expire, if the target pledge does not have an accurate clock. subsequent bootstrapping attempts. That this occurred is captured in the log information so that the registrar can make appropriate security decisions when a pledge joins the Domain. This is useful to support use cases where registrars might not be online during actual device deployment. Because this results in nit: I think that grammatically the "This" at the start of this sentence refers to the behavior described in the previous sentence (the availability of the log information) rather than the issuance of the nonceless voucher. Section 9 The autonomic control plane that this document provides bootstrap for is typically a medium to large Internet Service Provider organization, or an equivalent Enterprise that has signficant layer-3 router connectivity. (A network consistenting of primarily layer-2 nit: "is used in" -- the ACP is not the entire organization! Section 10.1 The MASA audit log includes a hash of the domainID for each Registrar a voucher has been issued to. This information is closely related to the actual domain identity, especially when paired with the anti-DDoS authentication information the MASA might collect. This could I thought I remembered some discussion of collecting this information and thus what sort of information might be collected, but searching for "DDoS" in the document didn't find it. There are a number of design choices that mitigate this risk. The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain. Is this really "privacy" or just "semi-plausible deniability"? Additionally the domainID captures only the unauthenticated subject key identifier of the domain. A privacy sensitive domain could It's interesting to see "unauthenticated" used here, since the domainID is deterministically generated from the pinned-domain-cert that is included in the voucher and inserted into the pledge's trust store. So in a sense it is a committal by "the domain" to tie that domain cert to that device or have the device otherwise be unusable. The subsequent text here seems to be suggesting that instead of having a single root CA cert used by all devices in the domain, distinct certs would be used for each device, thus attempting to remove an ability to associate devices with each other via joint domain membership. One might imagine doing this by entering intermediate CAs (or even leafs?) into the pinned-domain-cert field, but if those certs ever become visible (e.g., via certificate transparency), then the domainIDs can be independently computed and associated to the MASA audit log, and the issuer chain used to recorrelate the devices by domainID. So to fully protect privacy, the per-device pinned-domain-certs would need to be "root"s (i.e., self-issued), which greatly increases the manageability complexity and is in effect counter to the goals of ANIMA and BRSKI. Section 10.2 While the contents of the signed part of the pledge voucher request can not be changed, they are not encrypted at the registrar. The ability to audit the messages by the owner of the network prevents exfiltration of data by a nefarious pledge. The contents of an I think "prevents" is too strong -- steganography and concealed channels are really hard to completely defend against. "Gives a mechanism to defend against" would be more accurate, in my opinion. The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer: that an enterprise/ISP purchases routing products is hardly worth mentioning. Deviations would, however, be notable. Deviations in what sense? Section 10.3 4. There is a fourth case, if the manufacturer is providing protection against stolen devices. The manufacturer then has a responsability to protect the legitimate owner against fraudulent claims that the the equipment was stolen. Such a claim would cause the manufacturer to refuse to issue a new voucher. Should the device go through a deep factory reset (for instance, replacement of a damaged main board component, the device would not bootstrap. I'm not sure I understand this scenario -- is it talking about where a third party makes a false theft report in the hopes that the real owner will have to do a deep reset and then have the device fail to bootstrap because of the reported theft? Section 11 To facilitate logging and administrative oversight, in addition to triggering Registration verification of MASA logs, the pledge reports I'm not sure if "Registration verification" is a typo or not. registrar. This is mandated anyway because of the operational benefits of an informed administrator in cases where the failure is indicative of a problem. The registrar is RECOMMENDED to verify MASA I'd also expect some comment about the limited value of the additional information to an attacker in the context where the attacker already would know [other information]. To facilitate truely limited clients EST RFC7030 section 3.3.2 requirements that the client MUST support a client authentication model have been reduced in Section 7 to a statement that the registrar "MAY" choose to accept devices that fail cryptographic authentication. This reflects current (poor) practices in shipping But section 7 is non-normative! devices without a cryptographic identity that are NOT RECOMMENDED. I guess if we really wanted to disrecommend this practice we could split it out into a separate document that profiles core BRSKI for such usage. Section 11.1 this might be an issue during disaster recovery. This risk can be mitigated by Registrars that request and maintain long term copies of "nonceless" vouchers. In that way they are guaranteed to be able to bootstrap their devices. This, of course, comes with a different risk of what is something like a long-term credential existing that needs to be protected and stored. The issuance of nonceless vouchers themselves creates a security concern. If the Registrar of a previous domain can intercept protocol communications then it can use a previously issued nonceless voucher to establish management control of a pledge device even after having sold it. This risk is mitigated by recording the issuance of such vouchers in the MASA audit log that is verified by the subsequent Registrar and by Pledges only bootstrapping when in a factory default state. This reflects a balance between enabling MASA independence during future bootstrapping and the security of bootstrapping itself. Registrar control over requesting and auditing nonceless vouchers allows device owners to choose an appropriate balance. I would expect some discussion here about nonceless vouchers with/without expiration times. I also wonder whether the owner or registrar should expect to be doing soem periodic MASA audit log checking, akin to a CT auditor or monitor. of specific pledge devices, helps to mitigate this. Pledge signatures on the pledge voucher-request, as forwarded by the registrar in the prior-signed-voucher-request field of the registrar voucher-request, significantly reduce this risk by ensuring the MASA can confirm proximity between the pledge and the registrar making the request. This mechanism is optional to allow for constrained devices. Supply chain integration ("know your customer") is an And so the protection is only available when all devices served by the MASA are known to produce signed voucher-requests. additional step that MASA providers and device vendors can explore. In terms of adding some more crypto to the BRSKI-MASA flow that would prevent unauthenticated DoS? Section 11.2 I appreciate having this discussion present; thanks! The fake registrar (Rm) can obtain a voucher signed by the MASA either directly or through arbitrary intermediaries. Assuming that I'm not sure what sort of intermediary this is thinking about. This pledge voucher-request would be 'stale' in that it has a nonce that no longer matches the internal state of the pledge. In order to successfully use any resulting voucher the Rm would need to remove the stale nonce or anticipate the pledge's future nonce state. Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce. This gets a bit more complicated to reason about when we assume that a pledge will have multiple voucher requests out in parallel, instead of doing them in sequence and timing out (so that there is literally only one valid nonce at a given time)... Additionally, in order to successfully use the resulting voucher the Rm would have to attack the pledge and return it to a bootstrapping enabled state. This would require wiping the pledge of current ... and I think there is a different attack if the Rm is in a position to delay or drop network traffic between the pledge and the intended registrar, to cause Rm's voucher to be delivered first even though it is generated after the intended registrar's authorization process. The intended registrar would need to require reports on voucher processing status (or investigate their absence) in order to detect such a case. o Retreival and examination of MASA log information upon the occurance of any such unexpected events. Rm will be listed in the logs along with nonce information for analysis. How strongly guaranteed is it that a given device will only have a single specific MASA that it trusts to issue vouchers (and thus limit the scope of monitoring needed by the owner)? Section 11.3 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried upon seeing a manufacturer's trust anchor for the first time, and then the trust anchor would be installed to the trusted store. There are risks with this; even if the key to name is validated using something like the WebPKI, there remains the possibility nit: is this "key to name mapping"? Section 11.4 It is not entirely clear to me whether device manufacturers are set up with incentives to maintain a well-run secure CA with strong hardware protections on the offline signing key for the root CA, cycling through various levels of intermediates, etc., that CAs in the Web PKI do today. If the manufacturer uses a less stringent process, that would leave the manufacturer's key as a more tempting attack surface, and it may be worth some discussion here about what damage could be done with a compromised MASA signing key. E.g., would an attack require restoring devices to factory defaults or otherwise waiting for natural bootstrapping events to occur? Would the attacker need to be on-path? Etc. Section 13.2 I think CDDL needs to be a normative reference, as does RFC 7231. RFC 2473 is listed but not referenced in the text, as are RFC 2663, RFC 7217, and RFC 7575. Appendix B Discovery of registrar MAY also be performed with DNS-based service discovery by searching for the service "_brski- registrar._tcp.example.com". In this case the domain "example.com" is discovered as described in [RFC6763] section 11 (Appendix A.2 suggests the use of DHCP parameters). I'd suggest using "" per 6763 rather than "example.com". If no local proxy or registrar service is located using the GRASP mechanisms or the above mentioned DNS-based Service Discovery methods the pledge MAY contact a well known manufacturer provided bootstrapping server by performing a DNS lookup using a well known URI such as "brski-registrar.manufacturer.example.com". The details of the URI are manufacturer specific. Manufacturers that leverage this method on the pledge are responsible for providing the registrar service. Also see Section 2.7. It seems like there are some security considerations for device owners that may wish to prevent such registrars from being used. Do we need to direct them to run a firewall or similar? Appendix C I don't know how important file "ietf-mud-extension@2018-02-14.yang" is, but it seems a tad generic. Appendix D [Just checking that Michael wants sandelman.ca embedded in the final RFC] From nobody Wed Jul 10 23:37:18 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4E212008B; Wed, 10 Jul 2019 23:37:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2019 23:37:16 -0700 Archived-At: Subject: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 06:37:16 -0000 Adam Roach has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who invested time in developing this mechanism. I have two blocking comments that should be quite easy to resolve. --------------------------------------------------------------------------- §5: > MASA URI is "https://" iauthority "/.well-known/est". This doesn't make sense: iauthority is a component of IRIs, not of URIs. In URIs this is simply an "authority." It's not simply a terminology distinction: converting from an iauthority to an authority requires idna encoding. Please consult with an IRI expert (which I do not consider myself to be) to work out the proper terminology and procedures here. If you need help finding an expert, please let me know and I'll track someone down for you. --------------------------------------------------------------------------- §5.8: > Rather than returning the audit log as a response to the POST (with a > return code 200), the MASA MAY instead return a 201 ("Created") > RESTful response ([RFC7231] section 7.1) containing a URL to the > prepared (and easily cachable) audit response. The DISCUSS portion of my comment on this text is that it is unclear about how the URL is to be returned. It can just as easily be interpreted as returning it in a "Location" header field as it could as returning it in the response body -- or maybe somewhere else entirely (e.g., a link relation). This ambiguity will cause an interop issue. Please be explicit about precisely how the value is conveyed. While not part of the DISCUSS, I also have a fairly serious comment on the phrasing and citation of "return a 201 ("Created") RESTful response ([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion of Control Data header fields, rather than any general discussion of RESTful responses. It's worth noting that the term "RESTful" never appears in RFC 7231, so it's really unclear what section this was attempting to target. Perhaps 6.3.2? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Warren's discomfort with the models described in this document, especially in the context of device viability after companies disappear or change focus. It's not clear that this an unintended side effect of the model: much of the text around "legal ownership" seems aimed at subverting the doctrine of first sale/rule of exhaustion, and congruent laws around the world. While I sincerely appreciate the treatment of this issue in section 10.3, I think the document really needs *normative* behaviors defined that address the two issues of resale and device utility in a world where the device manufacturer (as that term is defined in section 1.2) is no longer available, rather than the high-level non-normative sketches currently provided for future study. In short, beyond the user-hostile effects of these two issues, I have ethical issues with the IETF publishing a protocol that promotes the unnecessary creation of e-waste; and, unless handled properly, that will be the inevitable result of the two factors I cite above. While this isn't part of my DISCUSS, I can't in good conscience ballot "No Objection" to a document that doesn't normatively address those issues. I urge the authors and working group to add text that does so. I do, however, recognize that the prospect of this happening at this stage of the process is vanishingly small. In the absence of such admittedly unlikely action, I plan to Abstain after my DISCUSS issue has been addressed. --------------------------------------------------------------------------- §2.1 > | +------v-------+ > | | (5) Enroll |<---+ (non-error HTTP codes ) > ^------------+ |\___/ (e.g. 201 'Retry-After') > | Enroll +------+-------+ > | Failure | I can't work out what a "Retry-After" would mean in a "201 Created" response. As noted above, section 5.6 of this document does indicate the use of a "Retry-After" header field with a 202 response, so I presume this diagram should say 202? --------------------------------------------------------------------------- §5: > BRSKI uses existing CMS message formats for existing EST operations. > BRSKI uses JSON [RFC7159] for all new operations defined here, and > voucher formats. RFC 7159 has been obsoleted by RFC 8259. --------------------------------------------------------------------------- §5.2 > The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header > indicating the acceptable media type for the voucher response. The Nit: ..."Accept" header field indicating... --------------------------------------------------------------------------- §5.5 > The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" > header indicating the response media types that are acceptable. This Nit: ..."Accept" header field indicating... > field and appropriate 'Accept header' field values from the physical Nit: ...'Accept header field' values... --------------------------------------------------------------------------- §5.6 > pledge would keep track of the appropriate Retry-After header values Nit: "...Retry-After header field values..." > desired type or using the desired algorithms (as indicated by the > Accept: headers, and algorithms used in the signature) cannot be Nit: "...Accept: header fields, ..." > The voucher response format is as indicated in the submitted accept > header or based on the MASA's prior understanding of proper format Nit: "...Accept header field..." --------------------------------------------------------------------------- §5.6 > { > "ietf-voucher:voucher": { > "nonce": "62a2e7693d82fcda2624de58fb6722e5", > "assertion": "logging" > "pinned-domain-cert": "base64encodedvalue==" > "serial-number": "JADA123456789" > } > } This JSON is syntactically invalid. Please run this example and all other instances of JSON in this document through a validation tool. With a reasonably modern version of nodejs, validation can be as simple as something like: node -e 'console.log(JSON.stringify(JSON.parse(` { "ietf-voucher:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "assertion": "logging" "pinned-domain-cert": "base64encodedvalue==" "serial-number": "JADA123456789" } } `)));' If the JSON is valid, you'll get no errors. --------------------------------------------------------------------------- §5.7: > { > "version":"1", > "Status":FALSE /* TRUE=Success, FALSE=Fail" > "Reason":"Informative human readable message" > "reason-context": { additional JSON } > } Please see https://tools.ietf.org/html/rfc8259#section-3 -- A JSON value MUST be an object, array, number, or string, or one of the following three literal names: false null true The literal names MUST be lowercase. No other literal names are allowed. There are also a number of other syntax errors in this JSON example, even setting aside the "additional JSON" indication. --------------------------------------------------------------------------- §5.8: > A MASA that returns a code 200 MAY also include a Location: header > for future reference by the registrar. Nit: "Location: header field" Also, it's not 100% clear what the registrar would use this URI for. Please explain in the document. --------------------------------------------------------------------------- §5.8.1: > { > "version":"1", > "events":[ > { > "date":"", > "domainID":"", > "nonce":"" > "assertion":"" > "truncated":"" > }, > { > "date":"", > "domainID":"", > "nonce":"" > "assertion":"" > } > ], > "truncation": { > "nonced duplicates": "", > "nonceless duplicates": "", > "arbitrary": "" > } > } This JSON is syntactically invalid. Please validate. --------------------------------------------------------------------------- §5.8.1: > Distribution of a large log is less than ideal. This structure can > be optimized as follows: Nonced or Nonceless entries for the same > domainID MAY be truncated from the log leaving only the single most Nit: "truncate" means to shorten something by removing only the beginning or only the end. I believe that you mean "omitted" (here and elsewhere in this section). --------------------------------------------------------------------------- §5.9.4: > { > "version":"1", > "Status":TRUE /* TRUE=Success, FALSE=Fail" > "Reason":"Informative human readable message" > "reason-context": "Additional information" > } This JSON is syntactically invalid. Please validate. --------------------------------------------------------------------------- §6: > In the BRSKI context, the EST "Content-Transfer-Encoding" header if > present, SHOULD be ignored. This header does not need to included. Nit: "...header field, if present..." Nit: "This header field does not..." --------------------------------------------------------------------------- §8.1: > This document extends the definitions of "est" (so far defined via > RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ > well-known-uris.xhtml" registry as follows: > > o add /.well-known/est/requestvoucher (see Section 5.5 ) > > o add /.well-known/est/requestauditlog (see Section 5.7) The .well-known registry does not contain sub-paths under the path element that appears after ".well-known". I note that "est" has already been registered by RFC 7030. There are a bunch of ways this can be handled, the easiest of which would be a request for the IANA to add this RFC alongside RFC 7030 to the entry for "est." More complex solutions would be selecting a different path than "est", or establishing a separate sub-registry for paths under the "est" well-known path. --------------------------------------------------------------------------- §8.4: > Service Name: _brski-proxy ... > Service Name: _brski-registrar You almost certainly don't want the service name to contain a leading underscore. That is added as part of the DNS-SD resolution process, but not part of the service name itself. --------------------------------------------------------------------------- Appendix B: > For example, if the first > Multicast DNS _bootstrapks._tcp.local response doesn't work then the > second and third responses are tried. I got a little lost here. Where is the "bootstrapks" service defined? I don't see it defined in this document or registered at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=bootstrapks From nobody Thu Jul 11 06:20:47 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73E120077; Thu, 11 Jul 2019 06:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2019 06:20:38 -0700 Archived-At: Subject: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:20:39 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this document. Despite comments/DISCUSSes raised, this was a good read. 1) In Section 5: o In the language of [RFC6125] this provides for a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. The SERIALNUM-ID whitelist is collated according to manufacturer trust anchor since serial numbers are not globally unique. I think now you are just inventing things. Please define what exactly SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed. 2) In 5.6: assertion: The method used to verify assertion. See Section 5.5.5. Section 5.5.5 doesn't define syntax of this field in enough details to implement. Can it contain one of the allowed values (like C enum)? 3) In 5.8 This is done with an HTTP GET using the operation path value of "/.well-known/est/requestauditlog". Here you say to use HTTP GET. The registrar SHOULD HTTP POST the same registrar voucher-request as But you only define how to use POST. I think the first "GET" is supposed to be "POST". 4) In 5.8.1: Format of different fields is not defined, so this is not interoperable. 5) In 8.1: This document extends the definitions of "est" (so far defined via RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ well-known-uris.xhtml" registry as follows: o add /.well-known/est/requestvoucher (see Section 5.5 ) o add /.well-known/est/requestauditlog (see Section 5.7) The .well-known URIs IANA registry doesn't list anything below the first level (i.e. "est" in your case). So I think you really want to have 2 IANA actions here: a) Add the reference to this document as another reference for "est". b) create a new registry of "est" URIs and add your 2 URIs above to it and also populate other entries from the original EST RFC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The first mention of HTTP 1.1 needs a Normative reference. 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices Upon successfully validating a voucher artiface, a status telemetry MUST be returned. See Section 5.7. "artiface" is an unfortunate typo. I think you meant "artifact" here. In 2.3.2: As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in this extension, including the scheme, iauthority, and ipath. As a consideration to constrained systems, this MAY be reduced to only the iauthority, in which case a scheme of "https://" and ipath of "/.well-known/est" is to be assumed, as explained in section Section 5. This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here. This would also avoid the need to use SHOULD and MAY above. In 2.3.2: "https" URI scheme needs a Normative reference. 2.7. Cloud Registrar If the pledge uses a well known URI for contacting a cloud registrar an Implicit Trust Anchor database (see [RFC7030]) MUST be used to authenticate service as described in [RFC6125]. Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified: a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards allowed in any of these? 4. Proxying details (Pledge - Proxy - Registrar) In order to permit the proxy functionality to be implemented on the maximum variety of devices the chosen mechanism SHOULD use the minimum amount of state on the proxy device. What does this mean? How can compliance with this SHOULD be evaluated? I think you want to use lower case "should" here. In 5.7 (and a similar issue elsewhere): { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail" This is not valid JSON, this is not even valid pseudo-JSON. Please move the comment: TRUE=Success, FALSE=Fail After this block to avoid confusion. Please add missing "," after each attribute value "Reason":"Informative human readable message" "reason-context": { additional JSON } } From nobody Thu Jul 11 06:38:50 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6508D120077; Thu, 11 Jul 2019 06:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2019 06:38:48 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:38:49 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's discuss that the conclusion of section 10(.3) should be to recommend a manual configuration mode. Also with respect to section 10.2: if ownership is "enforced" by the manufacturer, there should also probably be a way for the buyer to check if ownership was transferred by the saler during the re-sale process. Two other small comments on more load related points: 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid head of queue problems wherein an attacker running a fake proxy or registrar could perform protocol actions intentionally slowly. The pledge SHOULD continue to listen to for additional GRASP M_FLOOD messages during the connection attempts." One minor comment: Maybe also say explicitly, while running in parallel, one should not send all initial messages at exactly the same time but pace them out (e.g. one every 3 secs) to avoid network overload when initial connectivity is very constraint. 2) sec 4.3: " It must be sufficiently low that the aggregate amount of periodic M_FLOODs from all EST servers causes negligible traffic across the ACP." I know this is a little bit a blurry requirement but I would still like to see a MUST here. Or maybe give an upper bound for the maximum frequency, e.g. MUST NOT send more than once per minute...? Not sure it there is a reasonable value here. From nobody Thu Jul 11 06:40:48 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312ED12027D; Thu, 11 Jul 2019 06:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2019 06:40:38 -0700 Archived-At: Subject: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:40:44 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, A. This is really a discuss discuss. With to little time to dig into the details it appears that this protocol is making i hack of its interface towards the its transport. It appears to attempt to use an HTTP rest interface, but then it is also have a lot of talking about requirement for the TLS connection underlying the HTTP. So to illustrate the issue I see here is what happens if one like to use QUIC as the underlying transport for the rest interface rather than TCP/TLS? So can this document achieve a clearer interface to the lower layers so that it will be simpler to move the protocol to another underlying version of the HTTP "transport"? B. Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. Referencing RFC 2616 that has been obsolete by RFC 7230 and companions. I do note that there are no normative reference for that part in this document. From nobody Thu Jul 11 06:46:12 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23941120077; Thu, 11 Jul 2019 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=E80BtrEa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yqUGb0Vw 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 vXtQDInuXQSY; Thu, 11 Jul 2019 06:45:58 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593161200A3; Thu, 11 Jul 2019 06:45:58 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 150144C8; Thu, 11 Jul 2019 09:45:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 11 Jul 2019 09:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=e UD2DA6Z8sZLoGgLvM+9JhJ4GMj6qkIp4AByzwnvEd8=; b=E80BtrEav2fWC8JBU MeTMJd62AIN1iATY+uTtMXz3rxdXnrDKkQh7BzvJAG5XMTAoEEjvxU5DPMAc3tfR t9giM2gcszDfBdmyDVk9yHi7NpPQL4rKbxpDXUC5srUwd7EBbFjvQ6Wh4UKyl0I/ xTaaOYUrc3wJx2zlLu27ByrjPWSQymLVQ3ZsGOAeoSrwAZGWnhA2j1eW4mEhb/xV CyYs0RGZh5L6MfQbc+tqgHlwnW8FAb4OFY4rHbw+ylT2E7BQamfvfbhG6Scl8WaG IcRwo676bW+pa/P4pPDKLSSlizEYiLNoH2ZAZccPZXJ3WX1LparvF/Vlb8p/d4kI ExETg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=eUD2DA6Z8sZLoGgLvM+9JhJ4GMj6qkIp4AByzwnvE d8=; b=yqUGb0Vwrb5XhMNj1XFBd/ykpvdE3uvYUk4fE1mznIwVLg7vNcG3g63U8 skkXsyZXMBpzhvquIS9RD+ZjQ03AhMyxnvn3C+MXGZSqqpY9kufUiHXem0n23wiS IWOGVx+FpFd6NACPt3egK3/C+wVGEBNxiNIwc7FSZUgiVVOyqnPgHo+JZ18ayrAv V55v6CDNgqUI+BphjP4v/6qWPjoPViCiwfkNRrt6NHuUHGaCB/g9TXWH0ugmriGj OstGNCjLHDCVAxR5cIyRiK2a7xhyKrLoZ6H7TBxQOIejoYxay7msqFafYu2fSZ0M SB1e+Gq3sQCuyeOMwPStEUIO9L7kw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeekgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrgestgho ohhpvghrfidrihhnqeenucffohhmrghinhepvgigrghmphhlvgdrnhgvthdpvgigrghmph hlvgdrtghomhenucfkphepudejfedrfeekrdduudejrdeludenucfrrghrrghmpehmrghi lhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id A99178005C; Thu, 11 Jul 2019 09:45:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <406.1562813786@localhost> Date: Thu, 11 Jul 2019 09:45:55 -0400 Cc: IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5BC8F1BD-C039-4066-8323-6E82D3AC4F1D@cooperw.in> References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> <406.1562813786@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:46:04 -0000 > On Jul 10, 2019, at 10:56 PM, Michael Richardson = wrote: >=20 >=20 > Alissa Cooper via Datatracker wrote: >> I apologize if I'm misunderstanding how this works, but I didn't see = much >> discussion in the document about the implications of the manufacturer = going out >> of business. Specifically, it seems like if a device ships with BRSKI = as its >> only available mechanism for bootstrapping and the manufacturer goes >=20 > Section 7 provides some detail on a number of mechanisms that a = manufacturer > could chose to include that would permit a device to be onboarded with > reduces levels of trust. > Section 7.2 specifically mentions onboarding via serial-console. Yes, but section 7 is non-normative (maybe? per Roman=E2=80=99s = DISCUSS). So is the conclusion a reader is supposed to draw that it=E2=80=99= s ok for manufacturers to ship devices with BRSKI as the exclusive = onboarding mechanism? The fact that this may already happen today with = other protocols doesn=E2=80=99t seem like a reason to perpetuate it. >=20 > (This situation is really no different from buying an iPhone 4 and = then > complaining that you can't make it work because Apple won't give you > software that is secure, and since it's insecure, they won't onboard = you, > except that you get a serial-console) >=20 >> =3D Section 1.3.1 =3D >=20 >> "But this solution is not exclusive to large equipment: it is = intended >> to scale to thousands of devices located in hostile environments, >> such as ISP provided CPE devices which are drop-shipped to the end >> user." >=20 >> I don't quite understand how this squares with the scope limitation = described >> in Section 1 and Section 9. If the whole network is professionally = managed by >> the ISP, what part would be the "hostile environment"? >=20 > The thousands of CPE devices (cable modems, VDSL modems, ISP provided = home > routers) can be taken apart by the home owner. If such devices have = IDevID > in a TPM module, then enrollment can be done securely. So a consumer user=E2=80=99s home network, including the user=E2=80=99s = CPE, is considered to be part of the ISP=E2=80=99s =E2=80=9Cprofessionally= managed=E2=80=9D network? And if the consumer needs to fallback to some = non-BRSKI mechanism he is expected to bootstrap the device via serial = console himself? Trying to see if I understand the scope limitations = explained in Section 9. Thanks, Alissa >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >=20 >> I think this document would benefit from two concise lists, with = notes about >> which items in each list are defined in this document and which ones = are not >> defined: (1) what is operationally required of a manufacturer to = support BRSKI, >> and (2) what is operationally required of a domain owner to support >> BRSKI. >=20 > We did start this document describing the protocol from the point of = view of > each party (Pledge, Proxy, Registrar and MASA). This would be the way = that > each instrument in an orchestra receives their music. >=20 > We found that readers found it very difficult to understand the big = picture, > so we now describe the protocol in time-sequence, the way that the = script for > a play would be described. >=20 > But, you are asking for Operational requirements, not protocol = requirements. > I agree that this would be useful, and it's something that I'd like to = write. > I would consider it more of a BCP, and I don't think we have the = experience > to write this down yet. >=20 >> =3D Section 2.3.1 =3D >=20 >> What precisely is meant by "TPM identification"? Could a citation be = provided? >=20 > I don't have a reference, I hope Max can provide one. > I imagine it would point to a TCG document. >=20 > It's a SubjectAltName extension that is in a TPM contained certificate = that > tells relying parties what TPM device it is. >=20 >> =3D Section 10.1 =3D >=20 >> "The domain can maintain some privacy since it has not necessarily = been >> authenticated and is not authoritatively bound to the supply chain." >=20 >> What does this mean? That the domain can expect the manufacturer not = to trust >> the domainID because it hasn't been authenticated? >=20 > The MASA has a list of devices, and for each device, it has a list of = current > and previous owners. This is the audit log. The MASA will disclose = this to > current and previous owners, if they can present a voucher-request = that was > =46rom the device. (section 5.8) >=20 > It's hard to understand what kind of attack there is, but imagine that = xyz.example.net > goes under, sells a huge stack of example.com 48-port 100G BFRs to = other > ISPs. (The manufacturer, example.com is still alive and well, and is = happy > to take 10% support contracts from 30 new customers as it authorizes = the > resale) >=20 > Someone gets the Registrar database from xyz. They can now discover = who > ownes all these BFRs... and(?)...profit. > Perhaps this needs to be coordinated with resale of some other device. > That can be done as, although the audit log does not list the actual > customer, it lists them by SHA-1 hash of public key. >=20 > So the sentence above notes that it's not like the Registrar told the > manufacturer who it was, if it didn't authenticate. As such, either > xyz.example.net or the new owners could generate a new domainID, and > register each device uniquely. > (They want to use some kind of ONION routing to obfuscate their IP = address > too, but that's instantly defeated if they authenticate with TLS 1.2 > using a ClientCertificate) >=20 > I'm sure that we could improve this examplanation, but I'm not exactly = sure > how yet. >=20 >> =3D Section 10.2 =3D >=20 >> "The above situation is to be distinguished from a residential/ >> individual person who registers a device from a manufacturer: that an >> enterprise/ISP purchases routing products is hardly worth mentioning. >> Deviations would, however, be notable." >=20 >> What does the last sentence mean? >=20 > A residential ISP that buys 10,000 Linksys CPE routers is = unremarkable. > When the same ISP buys 10,000 Internet connectable sex toys as well, = that > might represent some kind of change in business plans. > Would a PC vendor be interested if some Enterprise customer suddenly = bought > only tablets? >=20 > The BRSKI-MASA connection does not reveal what is bought, but it does = reveal > who is doing business with whom, and it may also reveal volume. This = is > just traffic analysis. Christian Hopps has a nice document on = defeating that, btw. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- From nobody Thu Jul 11 07:33:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2CC120180; Thu, 11 Jul 2019 07:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cNDipXdl-CX4; Thu, 11 Jul 2019 07:33:24 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ADB12014F; Thu, 11 Jul 2019 07:33:24 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D368F54807D; Thu, 11 Jul 2019 16:33:19 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C4699440041; Thu, 11 Jul 2019 16:33:19 +0200 (CEST) Date: Thu, 11 Jul 2019 16:33:19 +0200 From: Toerless Eckert To: Alissa Cooper Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190711143319.vzt3zfsooi72f6jb@faui48f.informatik.uni-erlangen.de> References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 14:33:28 -0000 On Wed, Jul 10, 2019 at 01:42:30PM -0700, Alissa Cooper via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I apologize if I'm misunderstanding how this works, but I didn't see much > discussion in the document about the implications of the manufacturer going out > of business. Specifically, it seems like if a device ships with BRSKI as its > only available mechanism for bootstrapping and the manufacturer goes out of > business before the device is enrolled, the ability for the device to function > securely on the network may be significantly impaired if not impossible. It > seems like this document needs to make clear to manufacturers that a fallback > manual enrollment mechanism of some sort needs to be implemented along with > BRSKI in order to avoid this situation. Alissa, This is not a BRSKI specific issue/question. This is a question that equally applies to system design across pledge/client, server/registrar and masa when using Netconf Zerotouch (RFC8572). Or any other protocol relying on the RFC8366 voucher security architecture. In fact, BRSKI already answers a lot more system design issues in section 7 than RFC8572 does and RFC8572 did (appropriately) make it through to RFC without these system design options being elaborated on in that RFC. I consider all the system design aspects already covered in BRSKI to be somewhat opportunistic by now. In hindsight we could have a much shorter BRSKI protocol spec and a more comprehensive voucher architecture document applicable to netconf/BRSKI and other protocols (that leverage vouchers), but we didn't knew this when we started, and then it was too late. And of course WG reviewers kep hammering to answer questions ;-) So, to the extend that authors have not already spent cycles to write up things in BRSKI that really are not specific to BRSKI (such as section 7), i would appreciate if we would put put generic voucher security architecture option discussions into followup work written in a way that its understood how to apply to BRSKI, Netconf and any other (future) protocols. Btw: Primarily, as a customer i do not worry about the problem, because i want to use BRSKI to AVOID having to buy and store equipment. The typical use case is to do just-in-time-order of equipment shipped to insecure deployment location. If at all, its an issue of the reseller if the reseller wants to buy bulk, store and sell potentially years later. Something no sane reseller does these days with electronics equipment that quickly deteriorates in value. Now, when i need to (factory) reset a device years later i might run into the issue, and there are various solutions, but the best way for IETF to deal with this would be to have appropriate trust storage YANG models that express behaviour for such system reset or other operational device procedures. > = Section 1.3.1 = > > "But this solution is not exclusive to large equipment: it is intended > to scale to thousands of devices located in hostile environments, > such as ISP provided CPE devices which are drop-shipped to the end > user." > > I don't quite understand how this squares with the scope limitation described > in Section 1 and Section 9. If the whole network is professionally managed by > the ISP, what part would be the "hostile environment"? https://media04.kreiszeitung-wochenblatt.de/article/2017/10/24/8/277508_L.jpg?1554098709 (obviously BRSKI doesn't help against the explosives, that part of the picture is just for fun, but there are more subtle physical attack vectors against these physcially badly secured locations where BRSKI helps. And beside ATMs there are a lot more even less well protected retail locations with small routers in them connecting to corporate networks). I'll not answer to your discuss individually (leave it to the authors), but would like to mention that a coupe of your asks also relate to the "not BRSKI specific" or "better for a "BRSKI operations" document than further bloating the protocol spec. Cheers Toerless > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think this document would benefit from two concise lists, with notes about > which items in each list are defined in this document and which ones are not > defined: (1) what is operationally required of a manufacturer to support BRSKI, > and (2) what is operationally required of a domain owner to support BRSKI. > > = Section 2.3.1 = > > What precisely is meant by "TPM identification"? Could a citation be provided? > > = Section 10.1 = > > "The domain can maintain some privacy since it has not necessarily been > authenticated and is not authoritatively bound to the supply chain." > > What does this mean? That the domain can expect the manufacturer not to trust > the domainID because it hasn't been authenticated? > > = Section 10.2 = > > "The above situation is to be distinguished from a residential/ > individual person who registers a device from a manufacturer: that an > enterprise/ISP purchases routing products is hardly worth mentioning. > Deviations would, however, be notable." > > What does the last sentence mean? From nobody Thu Jul 11 08:08:30 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D8B12016D; Thu, 11 Jul 2019 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 29O-vN_fgthm; Thu, 11 Jul 2019 08:08:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11F31202EA; Thu, 11 Jul 2019 08:08:24 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E49754807D; Thu, 11 Jul 2019 17:08:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EF53F440041; Thu, 11 Jul 2019 17:08:19 +0200 (CEST) Date: Thu, 11 Jul 2019 17:08:19 +0200 From: Toerless Eckert To: Alissa Cooper Cc: Michael Richardson , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190711150819.lafanrg3326f557l@faui48f.informatik.uni-erlangen.de> References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> <406.1562813786@localhost> <5BC8F1BD-C039-4066-8323-6E82D3AC4F1D@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BC8F1BD-C039-4066-8323-6E82D3AC4F1D@cooperw.in> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:08:28 -0000 On Thu, Jul 11, 2019 at 09:45:55AM -0400, Alissa Cooper wrote: > > Alissa Cooper via Datatracker wrote: > >> I apologize if I'm misunderstanding how this works, but I didn't see much > >> discussion in the document about the implications of the manufacturer going out > >> of business. Specifically, it seems like if a device ships with BRSKI as its > >> only available mechanism for bootstrapping and the manufacturer goes > > > > Section 7 provides some detail on a number of mechanisms that a manufacturer > > could chose to include that would permit a device to be onboarded with > > reduces levels of trust. > > Section 7.2 specifically mentions onboarding via serial-console. > > Yes, but section 7 is non-normative (maybe? per Roman???s DISCUSS). So is the conclusion a reader is supposed to draw that it???s ok for manufacturers to ship devices with BRSKI as the exclusive onboarding mechanism? The fact that this may already happen today with other protocols doesn???t seem like a reason to perpetuate it. There are many different answers to that question for many different use cases. Thats not really a BRSKI question. Heck, i could have a device with BRSKI and Netconf zero-touch and voucher-via-USB stick, but no open console, so i have three "protocol" enrollment options, but they will all have the voucher as a single point of failure and i can easily come up with a use case where this is desired by the customer. > > The thousands of CPE devices (cable modems, VDSL modems, ISP provided home > > routers) can be taken apart by the home owner. If such devices have IDevID > > in a TPM module, then enrollment can be done securely. > > So a consumer user???s home network, including the user???s CPE, is considered to be part of the ISP???s ???professionally managed??? network? Pretty standard use case that CPE is provided/managed by the SP. Traditionally you got a routing CPE that you couldn't touch as the customer and the non-professional managed network started on the LAN ethernet ports of that CPE. Nowadays CPEs for more bitchy home customers have the SP boundary inside the software of the router, locking down all the WAN-side config and anything else the SP wants to lock down. Only some countries regulations force SPs to provide more liberal access, but whenever the CPE is fully provisioned by the customer alone, the support by the SP is often reduced. Again, 1001 use cases. In countries where there is a strong retail router market and end-users choose and deploy their router independent of the SP, BRSKI is still equally valuable, but now it would be the vendor of the retail router who would offer BRSKI/MASA and a customer web-portal to automate secure, automated deployment. > And if the consumer needs to fallback to some non-BRSKI mechanism he is expected to bootstrap the device via serial console himself? Trying to see if I understand the scope limitations explained in Section 9. Non-BRSKI operators have to prequalify by showing their knowledge of serial port console operations and morse code. (do i have to say *kidding* ?) How about: The zero-touch mechanism presented in this and the ACP document represents a signficiant efficiency: it avoids the need to ship devices to secure locations to provision them before deployment or to ship senior experts to remote and often insecure deployment locations to provision devices on-site with mechanisms as antiquated as craft serial consoles. Cheers Toerless > > Thanks, > Alissa > > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > > > >> I think this document would benefit from two concise lists, with notes about > >> which items in each list are defined in this document and which ones are not > >> defined: (1) what is operationally required of a manufacturer to support BRSKI, > >> and (2) what is operationally required of a domain owner to support > >> BRSKI. > > > > We did start this document describing the protocol from the point of view of > > each party (Pledge, Proxy, Registrar and MASA). This would be the way that > > each instrument in an orchestra receives their music. > > > > We found that readers found it very difficult to understand the big picture, > > so we now describe the protocol in time-sequence, the way that the script for > > a play would be described. > > > > But, you are asking for Operational requirements, not protocol requirements. > > I agree that this would be useful, and it's something that I'd like to write. > > I would consider it more of a BCP, and I don't think we have the experience > > to write this down yet. > > > >> = Section 2.3.1 = > > > >> What precisely is meant by "TPM identification"? Could a citation be provided? > > > > I don't have a reference, I hope Max can provide one. > > I imagine it would point to a TCG document. > > > > It's a SubjectAltName extension that is in a TPM contained certificate that > > tells relying parties what TPM device it is. > > > >> = Section 10.1 = > > > >> "The domain can maintain some privacy since it has not necessarily been > >> authenticated and is not authoritatively bound to the supply chain." > > > >> What does this mean? That the domain can expect the manufacturer not to trust > >> the domainID because it hasn't been authenticated? > > > > The MASA has a list of devices, and for each device, it has a list of current > > and previous owners. This is the audit log. The MASA will disclose this to > > current and previous owners, if they can present a voucher-request that was > > From the device. (section 5.8) > > > > It's hard to understand what kind of attack there is, but imagine that xyz.example.net > > goes under, sells a huge stack of example.com 48-port 100G BFRs to other > > ISPs. (The manufacturer, example.com is still alive and well, and is happy > > to take 10% support contracts from 30 new customers as it authorizes the > > resale) > > > > Someone gets the Registrar database from xyz. They can now discover who > > ownes all these BFRs... and(?)...profit. > > Perhaps this needs to be coordinated with resale of some other device. > > That can be done as, although the audit log does not list the actual > > customer, it lists them by SHA-1 hash of public key. > > > > So the sentence above notes that it's not like the Registrar told the > > manufacturer who it was, if it didn't authenticate. As such, either > > xyz.example.net or the new owners could generate a new domainID, and > > register each device uniquely. > > (They want to use some kind of ONION routing to obfuscate their IP address > > too, but that's instantly defeated if they authenticate with TLS 1.2 > > using a ClientCertificate) > > > > I'm sure that we could improve this examplanation, but I'm not exactly sure > > how yet. > > > >> = Section 10.2 = > > > >> "The above situation is to be distinguished from a residential/ > >> individual person who registers a device from a manufacturer: that an > >> enterprise/ISP purchases routing products is hardly worth mentioning. > >> Deviations would, however, be notable." > > > >> What does the last sentence mean? > > > > A residential ISP that buys 10,000 Linksys CPE routers is unremarkable. > > When the same ISP buys 10,000 Internet connectable sex toys as well, that > > might represent some kind of change in business plans. > > Would a PC vendor be interested if some Enterprise customer suddenly bought > > only tablets? > > > > The BRSKI-MASA connection does not reveal what is bought, but it does reveal > > who is doing business with whom, and it may also reveal volume. This is > > just traffic analysis. Christian Hopps has a nice document on defeating that, btw. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- -- --- tte@cs.fau.de From nobody Thu Jul 11 12:55:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FA6120121; Thu, 11 Jul 2019 12:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WdLnFWVEiQbB; Thu, 11 Jul 2019 12:55:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB96F12008B; Thu, 11 Jul 2019 12:55:35 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C2923818F; Thu, 11 Jul 2019 15:53:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DAA984E9; Thu, 11 Jul 2019 15:55:33 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 19:55:38 -0000 --=-=-= Content-Type: text/plain EXECSUM: Please stop beating us up for having solved the problem that the WG charter said we we should solve, and for having not solved a problem that the WG charter said was out-of-scope. Adam Roach via Datatracker wrote: > In short, beyond the user-hostile effects of these two issues, I have > ethical issues with the IETF publishing a protocol that promotes the > unnecessary creation of e-waste; and, unless handled properly, that will > be the inevitable result of the two factors I cite above. I really hate e-waste. More than many, I think. I have worked very hard in my spare time in years past on projects like cyanogen (when it was a thing) to continue to support perfectly good phones that were abandonned by their manufacturers. Much of the effort of supporting these phones has been because there is no protocol for the manufacturers to pass on the real ownership keys to the physical owner. BRSKI can do exactly this. *** but manufacturers have to want to do it *** I actually considered abandonning this document a year ago rather than build something that could potentially lock in relationships. Slowly I remembered that outside of the open source operating system on x86 platform (which now is ubiquitiously successful in the data center space), or openwrt on semi-documented SoC, everything else already is locked to the vendor. My opinion is that pretty much every IoT product out there is pretty much already e-waste because it does not support SUIT, RATS and BRSKI. But, ANIMA is not chartered to do residential IoT, but rather Enterprise/ISP equipment, and while we expect to use constrained-BRSKI for 6tisch, 6tisch is about industrial IoT equipment. In each case, the equipment is essentially e-waste as soon as the manufacturer stops producing security updates. So I totally understand and agree with your reluctance: if BRSKI gets into residential IoT, in the fly-by-night vendors that ship crap and then shut down, then I agree that it could be pretty user and environmentally hostile. Do I think that will happen? No: the fly-by-night vendors can't keep their telnetd debug ports closed, and they aren't going to implement BRSKI until such time as it's just there without them knowing it, and they start buying IoT system platforms from Intel/ARM/Microsoft/etc. at which point it will the manufacturers' *AUTHORIZED* signing authority. (Not the manufacturer) > While this isn't part of my DISCUSS, I can't in good conscience ballot "No > Objection" to a document that doesn't normatively address those issues. I > urge the authors and working group to add text that does so. I do, however, > recognize that the prospect of this happening at this stage of the process is > vanishingly small. In the absence of such admittedly unlikely action, I plan > to Abstain after my DISCUSS issue has been addressed. I am saddened by your cynicism, but I understand it. (I feel you might need a hug at this point) Can we write a protocol to replace trust anchors? Yes, easily. It's a one page yang model. There are vestiages of it a key anchor/management document that Kent Watsen wrote... I can't find it right now. We wanted to use in the early 6tisch zero-touch system that evolved into BRSKI. Can I force manufacturers to implement it? No. We aren't mandating any kind of CLI, NETMOD, SNMP, COMI, etc. interface in the BRSKI document, and we'd need at least one of them. We also had this debate back in November/December/January. I sure wish that your view had come forward then, rather than now. I don't know how to fix things to satisfy the resale problem, while not at the same time, opening the barn door to supply chain installed trojans. Please stop beating us up for having solved the problem that the WG charter said we we should solve, and for having not solved the problem that the WG charter said was out-of-scope. I'm curious if anyone has read Verner Vinge's Rainbow's End. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0nlDUACgkQgItw+93Q 3WV4MggAgXI+awYUjGAa4sc3ws/MIKquGMC70zGa3WXxHRRxrZDWc0EGwdu3tNwk L5XOQW6mc91yZ4xqcLzJTAig0kY3E2umvkDSLbAm9ItqEHil2VQC2vw37deF5qbh UX2ZtIcsYtkYDoc8bUOABKWSTjIMuEw7WrncxDB5dfXI2CpT5vwZzaH33lcejZuj tpJs0iAjJPizU5E++gZpSa5NZ282sa5RjWNkrrpSLiKhTuhBzWHvkoV7ZljETnSX Jp+N5X+V8+/7C6T5D8U8xaqcxf0LeJsBw3gDtQTKV5VtuQ5/queBodJI3Ez5bID5 l7aNDsJNZxpF8O6N3kaxTaBYiZs79w== =Z9uo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 11 13:02:15 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5C212013B; Thu, 11 Jul 2019 13:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Gtuy72QDoaSI; Thu, 11 Jul 2019 13:02:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B25F120155; Thu, 11 Jul 2019 13:02:02 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 282493818F; Thu, 11 Jul 2019 15:59:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 709994E9; Thu, 11 Jul 2019 16:02:01 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:02:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adam Roach via Datatracker wrote: > =C2=A75: >> MASA URI is "https://" iauthority "/.well-known/est". > This doesn't make sense: iauthority is a component of IRIs, not of UR= Is. In > URIs this is simply an "authority." It's not simply a terminology dis= tinction: > converting from an iauthority to an authority requires idna encoding.= Please > consult with an IRI expert (which I do not consider myself to be) to = work out > the proper terminology and procedures here. If you need help finding= an > expert, please let me know and I'll track someone down for you. okay, this one is my fault. I agree, we should have consulted an expert. I thought I was being clever. Please, can you find us an expert, if you think we should go this direction. I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the only reason to RFC3987 instead of RFC3986 is because one might have legacy systems that couldn't handle idna. Since I thought we had a greenfield her= e, I figured we could specify the superset. I can easily make this "authority" and RFC3986. Please advise. Some background: this text is slightly new, and is the result of interop failures. I had placed "https://example.com/" in the certificate, while another implementer placed "example.com:9443/.well-known/est" in, assuming = that "https:" was naturally implied. So, we disagreed what the base was, and we then agreed that there were sometimes reasons to include the the entire URL, but that less is better. We then looked for what the term for the "hostname:port" part was, and found 3986 and 3987. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0nlbkACgkQgItw+93Q 3WVAfAf/cw7VhoSRIEB7xK924tYNIoAU3TW+5O8s0vtCnvgy+XCg9qBjt12YXBvn w8Eu28x8YHYR6pIapz6Du/WhGW5IRhCLkwO4c/QLlKunvYUo2UpRTEoOD1Hf1Q05 j8ksLMprL0cpfd7INLyfgM9Sg2Zmx9c5Xz2UHgynITlARTncKDXzhgU7KHF1PJ5u xTArgZ3alRPS0crAlCcto8YoqDblnZ7VtZpW8lqPXKRWkK360fGRzAVdj2ICMgGU uTQFQfEdp1s5o2/66cyKkS9Vb1yyNB0kzKOP4myjQHBYhpWBGZAx/EP1M7pmIZ/N W7DnVWCnUvRV0rC0o0eMWOPH0EIQlA== =QZJz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 11 13:05:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E3120121; Thu, 11 Jul 2019 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Dn_bSwdrnJEs; Thu, 11 Jul 2019 13:05:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD63A1201DC; Thu, 11 Jul 2019 13:05:11 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CCE23818F; Thu, 11 Jul 2019 16:03:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C332E4E9; Thu, 11 Jul 2019 16:05:10 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:05:17 -0000 <#secure method=3Dpgpmime mode=3Dsign> Adam Roach via Datatracker wrote: > =C2=A75.8: >> Rather than returning the audit log as a response to the POST (with a >> return code 200), the MASA MAY instead return a 201 ("Created") >> RESTful response ([RFC7231] section 7.1) containing a URL to the >> prepared (and easily cachable) audit response. > The DISCUSS portion of my comment on this text is that it is unclear = about how > the URL is to be returned. It can just as easily be interpreted as re= turning > it in a "Location" header field as it could as returning it in the re= sponse > body -- or maybe somewhere else entirely (e.g., a link relation). Th= is > ambiguity will cause an interop issue. Please be explicit about preci= sely how > the value is conveyed. I see how this could be confusing. > While not part of the DISCUSS, I also have a fairly serious comment o= n the > phrasing and citation of "return a 201 ("Created") RESTful response > ([RFC7231] section 7.1)". Section 7.1 points to the top-level discuss= ion of > Control Data header fields, rather than any general discussion of RES= Tful > responses. It's worth noting that the term "RESTful" never appears i= n RFC > 7231, so it's really unclear what section this was attempting to targ= et. > Perhaps 6.3.2? Yes, that's what we are trying to target. I guess we also latched onto section 7.1.2 ("Location") Can you point me to another document that tries to specify the same thing. If we shouldn't say we are trying to be RESTful, what should we say? -- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- From nobody Thu Jul 11 13:53:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081E120043; Thu, 11 Jul 2019 13:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r4_uIhVW-cSM; Thu, 11 Jul 2019 13:53:18 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C470E12000F; Thu, 11 Jul 2019 13:53:18 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id k8so15715030iot.1; Thu, 11 Jul 2019 13:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d0hguIRoBWDT6WoHShAqxlk/pUv3oCVVdZxEqpiBisI=; b=f1EOs/gy52ZhtQJ8jvNdL1Vpo1R9YkPs5ZKaHZvoh9YrHSATxeI2xaHvYMyCv0DG74 gjGD4phTRTYCpp6B02G00WEVRaWQGLT5DBM/wcuBuF70XQra74kpK5qtewA7udin7d5n TfgjYZY1XRUaHvgXIL5jz96lUMwC/xd1hjTVTLskpC+wPoI+gmKAEBkAAab3twgzVglU MS0cfLgFu+fBzY9UADyuZKwVKagXveYlO/lIE1H3OywVbAFSaDNxGQrwOzy56ALr16uE 2GMBFv9xBrHSeI7BGJucGqSZvcrOBZvRzrkxVaFPgTeJu1oI68o8tsEqgJrLaiRObKbe K1yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d0hguIRoBWDT6WoHShAqxlk/pUv3oCVVdZxEqpiBisI=; b=i37Ozn9q87h+h7rsaz8O5t++MZ1PrHWdvVlyAC6UKKSZ6S8QNsBSF/9F+jEGwUW4rv gyQLFxUmc+I73JaCTEVJF2vzHg25+rINB13847AFIr0VL3pzq4gckp9BrH9cX8pv+F5H BbYJQANrbAbdSUk9qJrxML9PRVqUHzEUfbnWnoEq/iF5EN9HTzIXiOuX8zyIGhkER27u TZNHdxooLMMds0tKQTc5ORRHnq1gH/6RhKD2gDUWFuw8on+QShy7J/CMgUa0us9Tm74S aUIKRF2rEtY6vBzG/o5L8K9Chm5qZoNmtIO2SwjcEPJU7pdrinCHBaDBBqbeqVLfHqvJ ExBQ== X-Gm-Message-State: APjAAAXR2VjB0nhLvOyyuGfgyw1Tlf34EqgX0Xf8vKiA8LcQBLVaJg0U PQJ6R22X3Uevjr+bCUAHS5qkRPRYR8K4d6LH6/8= X-Google-Smtp-Source: APXvYqyPOvK0lPrKIQVhZHdzpssbGQYTiH/OeITWZfpHcceoszsykjpJA22DdBTYFx88auGY78d0BdgXhUUWVYkDM9Y= X-Received: by 2002:a5d:9e49:: with SMTP id i9mr5056012ioi.290.1562878397841; Thu, 11 Jul 2019 13:53:17 -0700 (PDT) MIME-Version: 1.0 References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <19180.1562875321@localhost> In-Reply-To: <19180.1562875321@localhost> From: Ted Hardie Date: Thu, 11 Jul 2019 13:52:51 -0700 Message-ID: To: Michael Richardson Cc: Adam Roach , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb0822058d6dfb7c" Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:53:22 -0000 --000000000000bb0822058d6dfb7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson wrote: > > Adam Roach via Datatracker wrote: > > =C2=A75: > > >> MASA URI is "https://" iauthority "/.well-known/est". > > > This doesn't make sense: iauthority is a component of IRIs, not of > URIs. In > > URIs this is simply an "authority." It's not simply a terminology > distinction: > > converting from an iauthority to an authority requires idna > encoding. Please > > consult with an IRI expert (which I do not consider myself to be) t= o > work out > > the proper terminology and procedures here. If you need help > finding an > > expert, please let me know and I'll track someone down for you. > > okay, this one is my fault. > I agree, we should have consulted an expert. I thought I was being cleve= r. > Please, can you find us an expert, if you think we should go this > direction. > > I thought IRIs were supersets of URIs, and that all URIs were IRIs, and t= he > only reason to RFC3987 instead of RFC3986 is because one might have legac= y > systems that couldn't handle idna. Since I thought we had a greenfield > here, > I figured we could specify the superset. > > It is correct that all IRIs are URIs, but the core purpose of the IRI was to be a presentation format. The presumption was that you turn it into wire-format (that is a URI) whenever you passed it to the protocol machinery that were going to retrieve a resource or take some other action over the network. For something that is already a URI, this is a null transform. For everything else, there's a set of steps in 3987, which includes ToASCII for ireg-name components which are domain names. I would personally not suggest using IRIs here, given that the scheme (https) is expected to retrieve a resource at a well-known location and thus will always have to be mapped to a URI to do the retrieval (rather than used in a string comparison or something similar) . RFC 5280, which this cites, actually goes through the steps pretty well, and I think the complexity there demonstrates the advantage for constrained devices of always using the URI form. Just a personal opinion, obviously, and I also would not class myself as an expert here. Ted > I can easily make this "authority" and RFC3986. > Please advise. > > Some background: this text is slightly new, and is the result of interop > failures. I had placed "https://example.com/" in the certificate, while > another implementer placed "example.com:9443/.well-known/est" in, > assuming that > "https:" was naturally implied. > > So, we disagreed what the base was, and we then agreed that there were > sometimes reasons to include the the entire URL, but that less is better. > We then looked for what the term for the "hostname:port" part was, and > found 3986 and 3987. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --000000000000bb0822058d6dfb7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Thu, Jul 11, 2019 at 1:02 P= M Michael Richardson <mcr+iet= f@sandelman.ca> wrote:

Adam Roach via Datatracker <noreply@ietf.org> wrote:
=C2=A0 =C2=A0 > =C2=A75:

=C2=A0 =C2=A0 >> MASA URI is "https://" iauthority "/.= well-known/est".

=C2=A0 =C2=A0 > This doesn't make sense: iauthority is a component o= f IRIs, not of URIs. In
=C2=A0 =C2=A0 > URIs this is simply an "authority." It's n= ot simply a terminology distinction:
=C2=A0 =C2=A0 > converting from an iauthority to an authority requires i= dna encoding. Please
=C2=A0 =C2=A0 > consult with an IRI expert (which I do not consider myse= lf to be) to work out
=C2=A0 =C2=A0 > the proper terminology and procedures here.=C2=A0 If you= need help finding an
=C2=A0 =C2=A0 > expert, please let me know and I'll track someone do= wn for you.

okay, this one is my fault.
I agree, we should have consulted an expert.=C2=A0 I thought I was being cl= ever.
Please, can you find us an expert, if you think we should go this direction= .

I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the=
only reason to RFC3987 instead of RFC3986 is because one might have legacy<= br> systems that couldn't handle idna.=C2=A0 Since I thought we had a green= field here,
I figured we could specify the superset.

It is correct that all IRIs are URIs, but the core pu= rpose of the IRI was to be a presentation format.=C2=A0 The presumption was= that you turn it into wire-format (that is a URI) whenever you passed it t= o the protocol machinery that were going to retrieve a resource or take som= e other action over the network.=C2=A0 For something that is already a URI,= this is a null transform.=C2=A0 For everything else, there's a set of = steps in 3987, which includes ToASCII for ireg-name components which are do= main names.

I would personally not suggest us= ing IRIs here, given that the scheme (https) is expected to retrieve a reso= urce at a well-known location and thus will always have to be mapped to a U= RI to do the retrieval (rather than used in a string comparison or somethin= g similar) .=C2=A0=C2=A0 RFC 5280, which this cites, actually goes through = the steps pretty well, and I think the complexity there demonstrates the ad= vantage for constrained devices of always using the URI form.

Just a personal opinion, obviously, and I also would not cl= ass myself as an expert here.

Ted
= =C2=A0
I can easily make this "authority" and RFC3986.
Please advise.

Some background: this text is slightly new, and is the result of interop failures.=C2=A0 =C2=A0I had placed "https://example.com/" in the c= ertificate, while
another implementer placed "example.com:9443/.well-known= /est" in, assuming that
"https:" was naturally implied.

So, we disagreed what the base was, and we then agreed that there were
sometimes reasons to include the the entire URL, but that less is better. We then looked for what the term for the "hostname:port" part was= , and
found 3986 and 3987.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [





--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--000000000000bb0822058d6dfb7c-- From nobody Thu Jul 11 14:45:10 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348BA1200F8; Thu, 11 Jul 2019 14:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 szAPm585qT6P; Thu, 11 Jul 2019 14:45:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA212009E; Thu, 11 Jul 2019 14:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1213; q=dns/txt; s=iport; t=1562881503; x=1564091103; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=2q/WGS50VMnke/bMzVv2szP8LnJHv6zAuTQ0bdS+s1g=; b=T8gQACjCMLMiwIBRYgBufH5giYc0AYKJuNCTvSrWKCvYEGX+fFdl+48E uNQxuoNm/7E9oOfT9yRQkKWxw9FooQ8l6OHEwxXQ2ggtKlnAko5C4/SaH KBvwKkpegsGFNGSoTit5Jz2eroJ0AF4kprZve0omSfM7XBnLA0DUBGTbQ A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAChrCdd/5JdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGCFoE7ATKERIgcikSbB4F7AgcBAQEJAwEBLwE?= =?us-ascii?q?BhEACglMjNAkOAQMBAQQBAQIBBW2FSIVLBiNWEAs7BwICVwYKgysBggqsKYE?= =?us-ascii?q?yhUeEZhCBNAGBUIoOF4F/gTgfgkw+h04ygiYEjDWIN5VvCYIbgh+BDJBdG4I?= =?us-ascii?q?clWehcoMLAgQGBQIVgVA4gVgzGggbFWUBgkI9gjqODz0DkDYBAQ?= X-IronPort-AV: E=Sophos;i="5.63,480,1557187200"; d="asc'?scan'208";a="374323267" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 21:45:02 +0000 Received: from rtp-vpn3-403.cisco.com (rtp-vpn3-403.cisco.com [10.82.217.149]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x6BLivnj005338 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 21:44:59 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EDF7C926-77E1-41FA-B4ED-6347ACD43BCC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 23:44:55 +0200 In-Reply-To: <17580.1562874933@localhost> Cc: Adam Roach , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org To: Michael Richardson References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.82.217.149, rtp-vpn3-403.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:45:05 -0000 --Apple-Mail=_EDF7C926-77E1-41FA-B4ED-6347ACD43BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One thought: I think the simplest way to address the bulk of both Adam=E2=80=99s and = Warren=E2=80=99s concern is to require the device to emit via whatever = management interface exists, upon request, a voucher that it has signed = with its own iDevID. It would have to be nonceless with perhaps a long = expiry, and that would cover a number of other use cases as well. That = way if the manufacturer goes out of business, or if the owner wants to = transfer the device without manufacturer consent, there is a way = forward. Eliot --Apple-Mail=_EDF7C926-77E1-41FA-B4ED-6347ACD43BCC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSet1wAKCRBugA9nE248 uFI0AKDb+109DHDMpRpTDzEcuX2GqlTsUwCguAhvVyZaTm83AxEwMlI1SFTknt0= =JgF3 -----END PGP SIGNATURE----- --Apple-Mail=_EDF7C926-77E1-41FA-B4ED-6347ACD43BCC-- From nobody Thu Jul 11 14:49:13 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717581200F8; Thu, 11 Jul 2019 14:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JtBuJQaoBUY4; Thu, 11 Jul 2019 14:49:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7913612009E; Thu, 11 Jul 2019 14:49:03 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6BLmmnH025807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jul 2019 17:48:51 -0400 Date: Thu, 11 Jul 2019 16:48:48 -0500 From: Benjamin Kaduk To: Eliot Lear Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org Message-ID: <20190711214847.GA16418@kduck.mit.edu> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:49:05 -0000 On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote: > One thought: > > I think the simplest way to address the bulk of both Adam’s and Warren’s concern is to require the device to emit via whatever management interface exists, upon request, a voucher that it has signed with its own iDevID. It would have to be nonceless with perhaps a long expiry, and that would cover a number of other use cases as well. That way if the manufacturer goes out of business, or if the owner wants to transfer the device without manufacturer consent, there is a way forward. An interesting thought. Would there be a way (or a need) to usefully audit such voucher issuance? -Ben From nobody Thu Jul 11 14:49:31 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064A120123; Thu, 11 Jul 2019 14:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 ZRBNHK1ZUXtW; Thu, 11 Jul 2019 14:49:21 -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 B3200120112; Thu, 11 Jul 2019 14:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1562881761; x=1564091361; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=M/imyc8oFuksmO65Ui0R43yZAPwzpwTwmdLHdwWd2xQ=; b=Eu8oYCkTymaCKHsGr8MyOZDpGVPS7oabsI1z4WJG/RLoPWAsTMx6+qlx r7w6BWYdNTWuHw902F31DZRNOC32b92CsK2OX6LT4Bz9IS4sXEEADdKT/ T8Boh0mYUXrbXCiScqZVZDMbIXWUcA7zYofjNRqpgNibIl8T7oGyjk8qZ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAASridd/5ldJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBghaBOwEyKIQciByKRYIPmHiBewIHAQE?= =?us-ascii?q?BCQMBAS8BAYRAAoJTIzQJDgEDAQEEAQECAQVthUiFSgEBAQECASNWBQsLGCM?= =?us-ascii?q?HAgJXBgoJgyIBgXsPrCSBMoVHhGYQgTQBgVCKDheBf4E4H4JMPodOMoImBIw?= =?us-ascii?q?1iDeVbwmCG4IfgQyQXRQHmAOhcoMLAgQGBQIVgVA4gVgzGggbFWUBgkE+gjq?= =?us-ascii?q?ODz0DMJAGAQE?= X-IronPort-AV: E=Sophos;i="5.63,480,1557187200"; d="asc'?scan'208";a="589378043" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 21:49:19 +0000 Received: from rtp-vpn3-403.cisco.com (rtp-vpn3-403.cisco.com [10.82.217.149]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6BLnFrL018796 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 21:49:17 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A0B51367-4C1E-4F5C-AAC7-38EACACE60DD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 23:49:13 +0200 In-Reply-To: Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org To: Michael Richardson References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.82.217.149, rtp-vpn3-403.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:49:23 -0000 --Apple-Mail=_A0B51367-4C1E-4F5C-AAC7-38EACACE60DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to complete the thought: Whether such a voucher would be pinned is something we do not have to = specify, with the risks of it not being pinned being born by the owner. Eliot > On 11 Jul 2019, at 23:44, Eliot Lear wrote: >=20 > Signed PGP part > One thought: >=20 > I think the simplest way to address the bulk of both Adam=E2=80=99s = and Warren=E2=80=99s concern is to require the device to emit via = whatever management interface exists, upon request, a voucher that it = has signed with its own iDevID. It would have to be nonceless with = perhaps a long expiry, and that would cover a number of other use cases = as well. That way if the manufacturer goes out of business, or if the = owner wants to transfer the device without manufacturer consent, there = is a way forward. >=20 > Eliot >=20 >=20 --Apple-Mail=_A0B51367-4C1E-4F5C-AAC7-38EACACE60DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSeu2QAKCRBugA9nE248 uMs5AJoDUoESbNRmEMReUGjgZEYhfn/18ACdHkxawXqjjXGXtwY8IIvcoBxDOo8= =28dM -----END PGP SIGNATURE----- --Apple-Mail=_A0B51367-4C1E-4F5C-AAC7-38EACACE60DD-- From nobody Thu Jul 11 15:00:15 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F31120156; Thu, 11 Jul 2019 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 4xr8IhjpnfWG; Thu, 11 Jul 2019 15:00:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94E01200F8; Thu, 11 Jul 2019 15:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5450; q=dns/txt; s=iport; t=1562882411; x=1564092011; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=wBcAk9Hm9AwGMKHVpIWTE2+KMZirKN3fJTv/YqOedTU=; b=BCyTPs7FFHatphkEp7TzNBxtm97MN1zVlBM5sVlcC0uw0I5qLVsVkgOE Q0vKUwidbGPEHE7Kokg6VetJGvOe7ra5b2VmfGAsl2EJoj/aGMe9ZERsM r1/x2QtSuYvmpuXAxb/ChvkpqDxD8cl7S/Vxr4Qhe2YaRZyp6wFSu6xZz 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABvsCdd/5xdJa1lDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYIWgTsBMiiEHIgcikWBaiWSdoYCgXs?= =?us-ascii?q?CBwEBAQkDAQEvAQGEQAKCUyM0CQ4BAwEBBAEBAgEFbYVIhUoBAQEBAgEjVgU?= =?us-ascii?q?LCwQUIwcCAlcGCgmDIgGBew+sJoEyhUeEZhCBNAGBUIoOF4F/gREnDBOCTD6?= =?us-ascii?q?HTjKCJgSMNYg3lW8JghuCH4EMkF0bmAOhcoMLAgQGBQIVgVA4gVgzGggbFTs?= =?us-ascii?q?qAYJBPoIOGBSNUj09AzCQBgEB?= X-IronPort-AV: E=Sophos;i="5.63,480,1557187200"; d="asc'?scan'208,217";a="592565205" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 22:00:07 +0000 Received: from rtp-vpn3-403.cisco.com (rtp-vpn3-403.cisco.com [10.82.217.149]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x6BLxwjI006048 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 22:00:00 GMT From: Eliot Lear Message-Id: <29C66B88-3927-4243-BE69-A8148ADDE50A@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7FA8DA14-C215-4313-A005-95036CC7AE05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 23:59:57 +0200 In-Reply-To: <20190711214847.GA16418@kduck.mit.edu> Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org To: Benjamin Kaduk References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <20190711214847.GA16418@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.82.217.149, rtp-vpn3-403.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:00:14 -0000 --Apple-Mail=_7FA8DA14-C215-4313-A005-95036CC7AE05 Content-Type: multipart/alternative; boundary="Apple-Mail=_1F3742BD-92F4-4579-A55E-A44B24B306B8" --Apple-Mail=_1F3742BD-92F4-4579-A55E-A44B24B306B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 23:48, Benjamin Kaduk wrote: >=20 > On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote: >> One thought: >>=20 >> I think the simplest way to address the bulk of both Adam=E2=80=99s = and Warren=E2=80=99s concern is to require the device to emit via = whatever management interface exists, upon request, a voucher that it = has signed with its own iDevID. It would have to be nonceless with = perhaps a long expiry, and that would cover a number of other use cases = as well. That way if the manufacturer goes out of business, or if the = owner wants to transfer the device without manufacturer consent, there = is a way forward. >=20 > An interesting thought. Would there be a way (or a need) to usefully = audit > such voucher issuance? >=20 Now you=E2=80=99re asking tough questions ;-) =E2=80=9CUsefully audit=E2=80=9D is a bit loaded, but let me posit the = following functions: Produce a voucher with an expiry of X pinned to domain Y Show a record of vouchers you=E2=80=99ve produced Add (the hash of) voucher X to a revocation list. Again, I would be hesitant to mandate a particular protocol for this = sort of thing, but simply require the functions. In some cases it could = be CIP (Common Industrial Protocol) while in others it might be = Profinet, and perhaps it could be something we could shove into the TEAP = draft (draft-lear-eap-teap-brski), though I am not a big fan of that = approach. In other cases, it could be as simple as =E2=80=9CAlexa [do = one of the above]=E2=80=9D ;-) The key point here is that at least the first buyer should be able to = enjoy a seamless zero-touch onboarding experience. Eliot --Apple-Mail=_1F3742BD-92F4-4579-A55E-A44B24B306B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Jul 2019, at 23:48, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear = wrote:
One = thought:

I think the simplest way to = address the bulk of both Adam=E2=80=99s and Warren=E2=80=99s concern is = to require the device to emit via whatever management interface exists, = upon request, a voucher that it has signed with its own iDevID.  It = would have to be nonceless with perhaps a long expiry, and that would = cover a number of other use cases as well.  That way if the = manufacturer goes out of business, or if the owner wants to transfer the = device without manufacturer consent, there is a way forward.

An interesting thought. =  Would there be a way (or a need) to usefully audit
such voucher issuance?


Now = you=E2=80=99re asking tough questions ;-)

=E2=80=9CUsefully audit=E2=80=9D is a bit loaded, = but let me posit the following functions:

  • Produce a = voucher with an expiry of X pinned to domain Y
  • Show a = record of vouchers you=E2=80=99ve produced
  • Add (the = hash of) voucher X to a revocation list.

Again, I would be hesitant to mandate a particular = protocol for this sort of thing, but simply require the functions. =  In some cases it could be CIP (Common Industrial Protocol) while = in others it might be Profinet, and perhaps it could be something we = could shove into the TEAP draft (draft-lear-eap-teap-brski), though I am = not a big fan of that approach.  In other cases, it could be as = simple as =E2=80=9CAlexa [do one of the above]=E2=80=9D = ;-)

The key point here is that at = least the first buyer should be able to enjoy a seamless zero-touch = onboarding experience.

Eliot

= --Apple-Mail=_1F3742BD-92F4-4579-A55E-A44B24B306B8-- --Apple-Mail=_7FA8DA14-C215-4313-A005-95036CC7AE05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSexXQAKCRBugA9nE248 uMaRAKCyoH5BjFK4RY9kTiaMww3/NooQvACfcFvkPtaLIHGGFKN1YMQf+W41szM= =C2zN -----END PGP SIGNATURE----- --Apple-Mail=_7FA8DA14-C215-4313-A005-95036CC7AE05-- From nobody Thu Jul 11 15:26:03 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F851200DB; Thu, 11 Jul 2019 15:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 uxLoFJZLgzVv; Thu, 11 Jul 2019 15:25:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16681200B6; Thu, 11 Jul 2019 15:25:59 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6BMPnMD039956 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jul 2019 17:25:51 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562883952; bh=ImZn46W1nUIddpLmNX0v7XMXxCzPJGMeIu5iVMTfT8A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ZIzXvVpxx9M1Pv35o3imfOOoOxOQSqieKTTHMtnY77PlmMl1d2M9hSiv7OJVZtzwz UdBn1m1oMUsGiGQdzLoF/xf6LEtwalvyMXYfS1bxgeqEPuET0mT6WNeg+afpTDT0NR bh46nu42INtqTXuDJesVWuen+5VBdJClmE0VMDcI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> From: Adam Roach Message-ID: <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> Date: Thu, 11 Jul 2019 17:25:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <17580.1562874933@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:26:02 -0000 On 7/11/19 2:55 PM, Michael Richardson wrote: > EXECSUM: Please stop beating us up for having solved the problem that the WG > charter said we we should solve, and for having not solved a > problem that the WG charter said was out-of-scope. I apologize if the objection came off as harsh. My intention was to be clear, and that may have come off as more blunt as intended. I understand that there's a problem to be solved here, and I think there's a fairly simple solution that would satisfy the points I raise (at least, to the extent that the IETF can do so). > Adam Roach via Datatracker wrote: > > In short, beyond the user-hostile effects of these two issues, I have > > ethical issues with the IETF publishing a protocol that promotes the > > unnecessary creation of e-waste; and, unless handled properly, that will > > be the inevitable result of the two factors I cite above. > > I really hate e-waste. More than many, I think. > > I have worked very hard in my spare time in years past on projects like > cyanogen (when it was a thing) to continue to support perfectly good phones > that were abandonned by their manufacturers. > > Much of the effort of supporting these phones has been because there is no > protocol for the manufacturers to pass on the real ownership keys to the > physical owner. BRSKI can do exactly this. > > *** but manufacturers have to want to do it *** I completely agree with everything you just said, and sincerely thank you for the work you've done in this area. I think where our perspectives might diverge is our beliefs about what *we*, the IETF, can do about it in this specific case. The IETF, as a matter of practice, includes normative statements in documents all the time regarding processes that conformant implementations "MUST" follow for the sake of security. In many cases, the protocol works just fine if implementors ignore these requirements, which means that implementation of them resolves to exactly one thing: manufacturers have to want to do it. We have no enforcement, and frequently no means to easily detect of violations of these normative statements. And yet we make them. And we give them normative force. And this allows customers, researchers, and even in some cases regulators to use those statements as a stick to try to get vendors to behave. The smallest change that would satisfy my concern would be a statement that says that devices conformant to this specification MUST contain a local means of bootstrapping that does not rely on any specific server being available. As with the security requirements we write into our specs, we'll have no means of enforcement. But as with the security requirements we write into our specs, we'll give interested parties just that little bit more leverage that might tip the scales towards the correct behavior. That's all I'm asking for. [snip] > So I totally understand and agree with your reluctance: if BRSKI gets into > residential IoT, in the fly-by-night vendors that ship crap and then shut > down, then I agree that it could be pretty user and environmentally hostile. > Do I think that will happen? No: the fly-by-night vendors can't keep > their telnetd debug ports closed, and they aren't going to implement BRSKI > until such time as it's just there without them knowing it, and they start > buying IoT system platforms from Intel/ARM/Microsoft/etc. I'm not worried about fly-by-night vendors. I'm worried about acquisition of extremely reputable medium-sized businesses by one of the several behemoth vendors who, as a matter of policy, give newly acquired business units exactly one year to show >$1MUSD net profit per engineering head or be shut down. /a From nobody Thu Jul 11 15:52:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531AA12016B; Thu, 11 Jul 2019 15:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 8rvaUYuvKPTV; Thu, 11 Jul 2019 15:52:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08E8120041; Thu, 11 Jul 2019 15:52:24 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6BMqHip044115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jul 2019 17:52:19 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562885540; bh=yo306wkegEZV1ntlmYuG5EErP8dmNdZAJ/zt5dmqh4Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Vo7HTHq5HUY8HMRJMwfq3mzxEdqnvykwc4kVeEddBrtim9UbgU5eM7KqIMZ2cl7/v GskWF59J8pslA+uLMWG8h1kRnFQ7tewTAcCTEl2cSjWLFs6uZn5kFKsqKxNPfCTATc p/00rfoUbCRNHuU3rQFgYpHanBCd9enDGMjJgzaQ= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <20219.1562875510@localhost> From: Adam Roach Message-ID: Date: Thu, 11 Jul 2019 17:52:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20219.1562875510@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:52:27 -0000 On 7/11/19 3:05 PM, Michael Richardson wrote: > <#secure method=pgpmime mode=sign> > > Adam Roach via Datatracker wrote: > > §5.8: > > >> Rather than returning the audit log as a response to the POST (with a > >> return code 200), the MASA MAY instead return a 201 ("Created") > >> RESTful response ([RFC7231] section 7.1) containing a URL to the > >> prepared (and easily cachable) audit response. > > > The DISCUSS portion of my comment on this text is that it is unclear about how > > the URL is to be returned. It can just as easily be interpreted as returning > > it in a "Location" header field as it could as returning it in the response > > body -- or maybe somewhere else entirely (e.g., a link relation). This > > ambiguity will cause an interop issue. Please be explicit about precisely how > > the value is conveyed. > > I see how this could be confusing. > > > While not part of the DISCUSS, I also have a fairly serious comment on the > > phrasing and citation of "return a 201 ("Created") RESTful response > > ([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion of > > Control Data header fields, rather than any general discussion of RESTful > > responses. It's worth noting that the term "RESTful" never appears in RFC > > 7231, so it's really unclear what section this was attempting to target. > > Perhaps 6.3.2? > > Yes, that's what we are trying to target. > I guess we also latched onto section 7.1.2 ("Location") > > Can you point me to another document that tries to specify the same thing. > If we shouldn't say we are trying to be RESTful, what should we say? "HTTP", but even that may be unnecessary in this case. REST means... something. Exactly what depends on who you ask. In practice, the least controversial thing to do is avoid the term; and, if you're trying to describe a specific quality (e.g., idempotence), say so explicitly. For this document, I don't think you really care much the purported properties of REST -- by any definition -- and I suspect you don't conform to them, for at least some number of mutually incompatible and religiously-held definitions of that term. In any case, I don't think the reference adds anything to the text, regardless of whether it points to 7.1.2 or to 6.3.2. So I would propose something along the lines of:    Rather than returning the audit log as a response to the POST (with a 200    (OK) response code), the MASA MAY instead return a 201 (Created) response    containing a "Location" header field that indicates the location of the    prepared audit response. This allows the audit response to appear at a    location that enables caching. If that says something other than what you meant, let me know, and I'll try to fix it. /a From nobody Thu Jul 11 19:08:03 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CAA12047A; Thu, 11 Jul 2019 19:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 4rYwVFXMxw8M; Thu, 11 Jul 2019 19:07:53 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC07A120381; Thu, 11 Jul 2019 19:07:52 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C27kCa010436; Thu, 11 Jul 2019 22:07:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6C27kCa010436 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1562897266; bh=q37NWJsL0UnMsISB/GPgUehxQGoOWNvFBphqjByt2pM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=kh0fP06OJM4LHlx4tND0htZMZrPOTkG+OIwrlAHrDAP/g0zOGIQJhRROluPBBHQfA zerVJaRV52+4uBOwEj02lSp/NMPfGCCLc2PI5ut7oDnppGACqbN+57NKScIJhKPydp xxKxDfHkdPnSocp0VOssngBZhalkJCYmmZS3lRzw= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6C27h6f020112; Thu, 11 Jul 2019 22:07:43 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 11 Jul 2019 22:07:42 -0400 From: Roman Danyliw To: Michael Richardson CC: The IESG , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , Toerless Eckert , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) Thread-Index: AQHVNzqofsCsqOReA0CZ18RZO6kzX6bElxCAgAGmCTA= Date: Fri, 12 Jul 2019 02:07:41 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33CE3CD@marchand> References: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com> <2520.1562791883@localhost> In-Reply-To: <2520.1562791883@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 02:08:02 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Wednesday, July 10, 2019 4:51 PM > To: Roman Danyliw > Cc: The IESG ; draft-ietf-anima-bootstrapping- > keyinfra@ietf.org; Toerless Eckert ; anima- > chairs@ietf.org; anima@ietf.org > Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping- > keyinfra-22: (with DISCUSS and COMMENT) >=20 > Roman Danyliw via Datatracker wrote: > > (2) Section 5.8.1. The format of the MASA audit log seems > > underspecified. Is the JSON snippet presented here normative to > > describe the MASA audit log > > response? >=20 > Yes, it's intended to be normative. > How can we make it clearer without over-engineering this, remembering > that this is a PS, not IS, and the proof will be in the running-code. >=20 > Would you prefer to used CDDL or something like that to describe it? CDDL would be very nice, but I have a much lower bar. I would be happy wit= h a full field list (e.g., I noticed that "version" isn't explained anywher= e but appears in the examples; what's the format of the date?) and a statem= ent that the log be structured per the JSON example.=20 Roman > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jul 11 20:31:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEF12001E; Thu, 11 Jul 2019 20:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X9tORQ0hDGeT; Thu, 11 Jul 2019 20:31:03 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2C1120019; Thu, 11 Jul 2019 20:31:03 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id f25so3869428pgv.10; Thu, 11 Jul 2019 20:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GGwDS0JZmiKTYLHUJTa3zYieRl5vAHAyOgYCoTFmBFY=; b=ZLWGTN5dIXdsypjS5lyJ/ZVguMd0sJhtP7FhvHKotaKiuLUX4sHNwsZA4DFDPRkfIX qYiuLROikrIxi/geFhrEPjXx/1GQVIVOCuQF+wgUPvQ8b3tsT+grY07noTNjLvFvxrTj Z6gZ4bhTYlb6nTjl8r/eAvFOug48Yy6LqT1hWujFXTUDGLTQ4zl/fqcARTlWRZdPEdsD xMapqobQnweyIJ3U87Oof9Mj4YK6fsbXOF4vzU3+/PXyKQCM8ZC1O+teWDQfyY0eiRU1 h8zJdjv2i54qLb//fYWLSZATQH+z3+vDLCU8qGWieErcE24VX0goIfuj875IAz/bUqJj +mIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GGwDS0JZmiKTYLHUJTa3zYieRl5vAHAyOgYCoTFmBFY=; b=cBZIcXOYpXPjfCYXKG+MmgZibceyqw5QZi/RzEnZW/qlmweixf0WHnLiOh1/3NW382 t5dxsQX4oxANERUyltVKqdPx+B62B25DqewmzL0U+BL0Kf+dwRT6IZ2MKMqXcrobFGSY iUGH2mhKnx2MkV6fB6eI9bmOLMD+62/Ajg99sxcrHcQQijZRL3KVA5dhSM9WhTCoJfGW hw0d8cdivu2lXiGdhm/3cG8pXWW0b+jqom7ByRu26RBnH6sfQ4Q5K8bm+/A25x+bmW0H pQ240ias5t4Zyck8Z6RpihqIBKXs7eDQC/RYWHewEJIbKDoF6eP5I3Z1jCJrz84wlskG 8sbQ== X-Gm-Message-State: APjAAAUKUQwQMNAR17ilw49vbFcqqbctwmWgVDalNt/P7pEJM3+BhHEe br7+YamNfpU3xeDNxVV0drenXq5m X-Google-Smtp-Source: APXvYqxsbPruT6cV5wwrkVkx9+G/CEObQepgo71bOAJCjOMGQ4jWllO+0yWhg2kqIOt6xsQKPnX2vQ== X-Received: by 2002:a17:90a:37e9:: with SMTP id v96mr8706227pjb.10.1562902261996; Thu, 11 Jul 2019 20:31:01 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id 30sm19313946pjk.17.2019.07.11.20.30.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 20:31:01 -0700 (PDT) To: Adam Roach , Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <20219.1562875510@localhost> From: Brian E Carpenter Message-ID: <13c64298-fe6e-2d71-9523-3d0cce340463@gmail.com> Date: Fri, 12 Jul 2019 15:30:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 03:31:04 -0000 On 12-Jul-19 10:52, Adam Roach wrote: > On 7/11/19 3:05 PM, Michael Richardson wrote: >> <#secure method=3Dpgpmime mode=3Dsign> >> >> Adam Roach via Datatracker wrote: >> > =C2=A75.8: >> >> >> Rather than returning the audit log as a response to the POST = (with a >> >> return code 200), the MASA MAY instead return a 201 ("Created"= ) >> >> RESTful response ([RFC7231] section 7.1) containing a URL to t= he >> >> prepared (and easily cachable) audit response. >> >> > The DISCUSS portion of my comment on this text is that it is un= clear about how >> > the URL is to be returned. It can just as easily be interpreted= as returning >> > it in a "Location" header field as it could as returning it in = the response >> > body -- or maybe somewhere else entirely (e.g., a link relation= ). This >> > ambiguity will cause an interop issue. Please be explicit about= precisely how >> > the value is conveyed. >> >> I see how this could be confusing. >> >> > While not part of the DISCUSS, I also have a fairly serious com= ment on the >> > phrasing and citation of "return a 201 ("Created") RESTful res= ponse >> > ([RFC7231] section 7.1)". Section 7.1 points to the top-level d= iscussion of >> > Control Data header fields, rather than any general discussion = of RESTful >> > responses. It's worth noting that the term "RESTful" never app= ears in RFC >> > 7231, so it's really unclear what section this was attempting t= o target. >> > Perhaps 6.3.2? >> >> Yes, that's what we are trying to target. >> I guess we also latched onto section 7.1.2 ("Location") >> >> Can you point me to another document that tries to specify the same th= ing. >> If we shouldn't say we are trying to be RESTful, what should we say? >=20 >=20 > "HTTP", but even that may be unnecessary in this case. >=20 > REST means... something. Exactly what depends on who you ask. In=20 > practice, the least controversial thing to do is avoid the term;=20 I am unbelievably happy to read that. I thought it was forbidden to be an unbeliever in RESTfulness. > and, if=20 > you're trying to describe a specific quality (e.g., idempotence), say s= o=20 > explicitly. In the simplest possible terms, isn't the quality we require that an operation has unambiguously succeeded or unambiguously failed? But in fact, simply deleting the two occurrences of "RESTful" seems appropriate. Brian >=20 > For this document, I don't think you really care much the purported=20 > properties of REST -- by any definition -- and I suspect you don't=20 > conform to them, for at least some number of mutually incompatible and = > religiously-held definitions of that term. >=20 > In any case, I don't think the reference adds anything to the text,=20 > regardless of whether it points to 7.1.2 or to 6.3.2. So I would propos= e=20 > something along the lines of: >=20 > =C2=A0=C2=A0 Rather than returning the audit log as a response to the = POST (with=20 > a 200 > =C2=A0=C2=A0 (OK) response code), the MASA MAY instead return a 201 (C= reated)=20 > response > =C2=A0=C2=A0 containing a "Location" header field that indicates the l= ocation of the > =C2=A0=C2=A0 prepared audit response. This allows the audit response t= o appear at a > =C2=A0=C2=A0 location that enables caching. >=20 >=20 > If that says something other than what you meant, let me know, and I'll= =20 > try to fix it. >=20 > /a >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Fri Jul 12 00:27:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB46120128; Fri, 12 Jul 2019 00:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 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 d8eTZKz-BA-L; Fri, 12 Jul 2019 00:27:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAB21200DE; Fri, 12 Jul 2019 00:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4652; q=dns/txt; s=iport; t=1562916437; x=1564126037; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=OadvbSQv5qIUlEjyvX3h1g4ZMX+RQydipfMmN580Oxo=; b=CIK/1G3CSnd15vIc8JVd2Sqf+YnyY41l9bkSllkqF+uuy8zFMmsitFQw sbITSftR5o+Ng/baZJ2nLzrby+cVduE4IXlMcocsJpBNA6t9efjwimsRp 7WJtw2xkL06XJS0bB9glx9ukjpWk4bygZNEcmmVUxYKALXnSo8dzIr40F s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAAAiNShd/5pdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgRRTL4E7ATIoln2CD4cyi0aGAoF7AgcBAQEJAwEBLwEBhEA?= =?us-ascii?q?CglMjNgcOAQMBAQQBAQIBBW2FSIVKAQEBAQIBdAUFCwsEFCMLVwYTgyIBgXs?= =?us-ascii?q?PrTuFR4RiEIE0AYFQig4XgX+BEScfgkw+hC6DUoImBJRulXAJghuCH4EMkGA?= =?us-ascii?q?bmAWhc4MLAgQGBQIVgVcELYFYMxoIGxVlAYJBPoI6jg89AzCQTgEB?= X-IronPort-AV: E=Sophos;i="5.63,481,1557187200"; d="asc'?scan'208,217";a="592876056" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jul 2019 07:27:15 +0000 Received: from rtp-vpn3-403.cisco.com (rtp-vpn3-403.cisco.com [10.82.217.149]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6C7RBB1007664 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 07:27:14 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_17F8A2C5-AD67-452B-B8D7-61A3659287A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 12 Jul 2019 09:27:11 +0200 In-Reply-To: <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org To: Adam Roach References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.82.217.149, rtp-vpn3-403.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 07:27:20 -0000 --Apple-Mail=_17F8A2C5-AD67-452B-B8D7-61A3659287A7 Content-Type: multipart/alternative; boundary="Apple-Mail=_63A77013-A48E-41B4-844E-D21D16F57DAD" --Apple-Mail=_63A77013-A48E-41B4-844E-D21D16F57DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adam > On 12 Jul 2019, at 00:25, Adam Roach wrote: >=20 >=20 > The smallest change that would satisfy my concern would be a statement = that says that devices conformant to this specification MUST contain a = local means of bootstrapping that does not rely on any specific server = being available. As with the security requirements we write into our = specs, we'll have no means of enforcement. But as with the security = requirements we write into our specs, we'll give interested parties just = that little bit more leverage that might tip the scales towards the = correct behavior. I think this is easily possible within the paradigm of the document = after the device has first been onboarded. At this stage, I would also = suggest that the MUST be a SHOULD for another reason: there may be cases = where it is in the customer best interest to prevent onboarding of a = device just through proof of possession. I am thinking of anti-theft = mechanisms. Having a discussion of this and the risks of not having any = on-prem method ever seems like a reasonable add. Eliot --Apple-Mail=_63A77013-A48E-41B4-844E-D21D16F57DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Adam

On 12 Jul 2019, at 00:25, Adam Roach <adam@nostrum.com> = wrote:


The smallest change that would = satisfy my concern would be a statement that says that devices = conformant to this specification MUST contain a local means of = bootstrapping that does not rely on any specific server being available. = As with the security requirements we write into our specs, we'll have no = means of enforcement. But as with the security requirements we write = into our specs, we'll give interested parties just that little bit more = leverage that might tip the scales towards the correct = behavior.


I = think this is easily possible within the paradigm of the document after = the device has first been onboarded. At this stage, I would also suggest = that the MUST be a SHOULD for another reason: there may be cases where = it is in the customer best interest to prevent onboarding of a device = just through proof of possession.  I am thinking of anti-theft = mechanisms.  Having a discussion of this and the risks of not = having any on-prem method ever seems like a reasonable add.

Eliot
= --Apple-Mail=_63A77013-A48E-41B4-844E-D21D16F57DAD-- --Apple-Mail=_17F8A2C5-AD67-452B-B8D7-61A3659287A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSg2TwAKCRBugA9nE248 uGiJAKDOOTpIglmgTaDdBkKWo1JWpK8HdwCdGAea+55yRcxS4fDZ5tZehGC6uqs= =WyCc -----END PGP SIGNATURE----- --Apple-Mail=_17F8A2C5-AD67-452B-B8D7-61A3659287A7-- From nobody Fri Jul 12 08:21:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1112063C; Fri, 12 Jul 2019 08:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=aLimvUfm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aNsdzB2C 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 eTTTIiSUz4wO; Fri, 12 Jul 2019 08:21:31 -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 CCB38120634; Fri, 12 Jul 2019 08:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15835; q=dns/txt; s=iport; t=1562944891; x=1564154491; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DYmxI23DE0FuckApkmWmkwptiOiVmArg9Lv2foSSaac=; b=aLimvUfmQcnJd+m/g4IcRT4wUt482L3kH/KCpLU9kHRws9wtTwQ8Y5FY CcII6KBWSKqGT9/LeT3/o3zD7pdSAQcianobNGn1w9A8H5L0RKHk1wS2A sIe4cKypaEAZkPET98Fr0ZDwiC/XcaYy02+pwuP92zXxQLXR13xImzNa7 o=; IronPort-PHdr: =?us-ascii?q?9a23=3ASe3IaBXBpJRAa9W/ashVs0HYpy3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiBsVeVVxk+VmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAQBGpChd/49dJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgRQvJCwDalUgBAsUFAqEEoNHA45LgjaTHYRUglIDVAkBAQE?= =?us-ascii?q?MAQElCAIBAYRAAheCPyM3Bg4BAwEBBAEBAgEFbYU8DIVLAgEDEhEdAQEyBQE?= =?us-ascii?q?PAgEIOwQDAgICMBQRAgQOBSKDAAGBHU0DHQECDKBaAoE4iGBxgTKCeQEBBYU?= =?us-ascii?q?LGIISAwaBNAGLXheBf4ERJwwTgkw+gmEBAQIBgUhDgl0ygiaMLQ+CPIR+iGu?= =?us-ascii?q?NGG0JAoIZhliNMxuCLIckjjeLXIkekAcCBAIEBQIOAQEFgWYigVhwFWUBgkG?= =?us-ascii?q?CQTeDOoUUhT9yAYEojHErgQQBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,483,1557187200"; d="scan'208,217";a="589997679" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jul 2019 15:21:28 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x6CFLSnY005670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jul 2019 15:21:28 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Jul 2019 10:21:27 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Jul 2019 10:21:26 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Jul 2019 10:21:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HZBHagYZstlZq/+Kisvq4WPVALrsz6E/mpc2dxoArBwaR/jpu/bRn/8nnWg9VcQJE2cizOUDq+advRqQOz7hdUAOu66YlWvlA+iUz1tWYXn8bRJUqhsNFGsRjo2OLRvh2CeukG3Mswjf3JgmVIl4HR/2GEtOkzTOxwQjEm0QZXN91e/TldxCsxuaInCGjVrrajw/8rfSrX2xPiT7a0ujRbr4PWOB8W4aMuPjZ4K1q2tVwjpNacvC71eu0iNR18bNplnw8FJsRdH9q0+R9HP57WBZuduHK9E2/2B5YPEGB/Ef5cCkG99pL9tjgyCuGsWsslxGIQzfWJec77v6LmX8WQ== 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=DYmxI23DE0FuckApkmWmkwptiOiVmArg9Lv2foSSaac=; b=jvKd8wVEEd0LEY+2d3X7SKYwX8S/hq66GUq2Z5bXA4W9RRvX9Txtm3Ube2igFp4+LrKQLaFVTM6fn9e8ejEBYB384eLZxgWg7iSSKG/+d4eafecrCkPQCWUSnkfkTYpjH48M+1vcJWLGOxKdQpYhriFf+60kAX3zrI24mhpfCmw7QMqhmG9BnZTEivSBxCshNs5ZymoCniDhoParFHzE8xJd7sy/Oq7d5mcHWJ5snDnVtIEJb+FreRl1ZmROzRYlKiP1NKyxO2ugJh1QIWdTQ9q/9FW5xWLEpQF5gytx+U920cs/mR+R7zWqU0X8IEF4qg5+/xBCcbUIiJC8lFeKhg== 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=DYmxI23DE0FuckApkmWmkwptiOiVmArg9Lv2foSSaac=; b=aNsdzB2COkI4jxcqomhYVrLwP4VouRjKEqP0JWHZlZSn8cYkzf67dk/Rah9hmhmECEsBIG83nrx2IsiJb1tGuLZe1QPFP14x/MYJqTChQhmKTLS/RpYphrWAG0eHg1PiqVPSSM9HroNWXkvhzU6U1LvXdkGREV4fHlTPt5crg0c= Received: from BYAPR11MB3525.namprd11.prod.outlook.com (20.177.227.23) by BYAPR11MB3272.namprd11.prod.outlook.com (20.177.185.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 12 Jul 2019 15:21:25 +0000 Received: from BYAPR11MB3525.namprd11.prod.outlook.com ([fe80::cc5d:56b1:d49d:40b0]) by BYAPR11MB3525.namprd11.prod.outlook.com ([fe80::cc5d:56b1:d49d:40b0%6]) with mapi id 15.20.2052.020; Fri, 12 Jul 2019 15:21:25 +0000 From: "Max Pritikin (pritikin)" To: Eliot Lear CC: Adam Roach , Michael Richardson , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , Toerless Eckert , "anima@ietf.org" , The IESG , "anima-chairs@ietf.org" Thread-Topic: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) Thread-Index: AQHVN7Mam408jWZUSkSbpfvPpziaGKbF1cyAgAAp9gCAAJdHgIAAhH8A Date: Fri, 12 Jul 2019 15:21:25 +0000 Message-ID: <4BC524D0-04E7-4ACC-8638-453643961D15@cisco.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pritikin@cisco.com; x-originating-ip: [72.163.2.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c8c318d-9035-40f3-d0a6-08d706dc9ab3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3272; x-ms-traffictypediagnostic: BYAPR11MB3272: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(346002)(39860400002)(366004)(199004)(189003)(37006003)(54906003)(6506007)(71200400001)(71190400001)(66446008)(64756008)(66556008)(66946007)(66476007)(236005)(4326008)(6116002)(3846002)(76116006)(5660300002)(54896002)(6246003)(486006)(53936002)(8676002)(102836004)(606006)(76176011)(66066001)(25786009)(86362001)(53546011)(6512007)(6306002)(36756003)(14444005)(11346002)(6636002)(68736007)(33656002)(2906002)(229853002)(476003)(446003)(2616005)(81156014)(8936002)(81166006)(186003)(26005)(6486002)(14454004)(6436002)(256004)(7736002)(316002)(966005)(478600001)(99286004)(6862004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3272; H:BYAPR11MB3525.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KD2jkMuiX65ZpOSkkTHNCN0LYrsmxRSpaI/JuUECirPCHdcWz4VR+Wtxm3eAMDKfpNlILkJbsz0bn6SVm9x03XorQTcPJqLuQXKc1r4QpDWh6PaGzD0SOzlvHa2d2kDDjEw7raa4wf/VaZE8mtnlyXCYQ1AJ9bIO3khmGXXqFnWdyr5I/TOppi+WYukQigfWIjsQdOZdlNp3X0SBvqipY8Y3axD5/5TmpWrgUk5KkGlVs94eOFUzTEkfC3xuiK2TSBk6VUAMmM9gverzJJtDhjbvuEhfZYcXIFBTLyxlsoI/YuXAYPTi8HmOqkGJeeNENgQ48dya+xT0jRhYFbYnSTzso+kbC9jrSLqz0cB0b5RB45iZiwepavB/TyfVk27uJ/bgMP5J21MqLJ2TrS4wPtrYeM6Drx/IyjS21ZaWpj4= Content-Type: multipart/alternative; boundary="_000_4BC524D004E74ACC8638453643961D15ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c8c318d-9035-40f3-d0a6-08d706dc9ab3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 15:21:25.2482 (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: pritikin@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3272 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 15:21:36 -0000 --_000_4BC524D004E74ACC8638453643961D15ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGWUkgd2hhdCB5b3UgYWxsIGFyZSBkaXNjdXNzaW5nIGFyZSBwb3RlbnRpYWwgY2hhbmdlcyB0 byB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIG9mDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhLTIyI3NlY3Rpb24tNy4yDQoN ClByb2JhYmx5IHN0cmVuZ3RoZW5pbmcgdGhpcyBwYXJhZ3JhcGggZnJvbSBNQVkvU0hPVUxEIHRv IGEgTVVTVDoNCg0KICAgMy4gIFRoZSBwbGVkZ2UgTUFZIGhhdmUgYW4gb3BlcmF0aW9uYWwgbW9k ZSB3aGVyZSBpdCBza2lwcyB2b3VjaGVyDQogICAgICAgdmFsaWRhdGlvbiBvbmUgdGltZS4gIEZv ciBleGFtcGxlIGlmIGEgcGh5c2ljYWwgYnV0dG9uIGlzDQogICAgICAgZGVwcmVzc2VkIGR1cmlu ZyB0aGUgYm9vdHN0cmFwcGluZyBvcGVyYXRpb24uICBUaGlzIGNhbiBiZSB1c2VmdWwNCiAgICAg ICBpZiB0aGUgbWFudWZhY3R1cmVyIHNlcnZpY2UgaXMgdW5hdmFpbGFibGUuICBUaGlzIGJlaGF2 aW9yIFNIT1VMRA0KICAgICAgIGJlIGF2YWlsYWJsZSB2aWEgbG9jYWwgY29uZmlndXJhdGlvbiBv ciBwaHlzaWNhbCBwcmVzZW5jZSBtZXRob2RzDQogICAgICAgKHN1Y2ggYXMgdXNlIG9mIGEgc2Vy aWFsL2NyYWZ0IGNvbnNvbGUpIHRvIGVuc3VyZSBuZXcgZW50aXRpZXMNCiAgICAgICBjYW4gYWx3 YXlzIGJlIGRlcGxveWVkIGV2ZW4gd2hlbiBhdXRvbm9taWMgbWV0aG9kcyBmYWlsLiAgVGhpcw0K ICAgICAgIGFsbG93cyBmb3IgdW5zZWN1cmVkIGltcHJpbnQuDQoNCklmIHRoaXMgaXMgYSBzdWdn ZXN0ZWQgY2hhbmdlIHBsZWFzZSBjb21tZW50IG9uIHRoZSBzdWJzZXF1ZW50IHBhcmFncmFwaCB3 aGljaCByZWFkczoNCg0KSXQgaXMgUkVDT01NRU5ERUQgdGhhdCAidHJ1c3Qgb24gZmlyc3QgdXNl IiBvciBhbnkgbWV0aG9kIG9mIHNraXBwaW5nDQogICB2b3VjaGVyIHZhbGlkYXRpb24gKGluY2x1 ZGluZyB1c2Ugb2YgY3JhZnQgc2VyaWFsIGNvbnNvbGUpIG9ubHkgYmUNCiAgIGF2YWlsYWJsZSBp ZiBoYXJkd2FyZSBhc3Npc3RlZCBOZXR3b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQgW1JGQzUyMDld DQogICBpcyBzdXBwb3J0ZWQuICBUaGlzIHJlY29tbWVuZGF0aW9uIGVuc3VyZXMgdGhhdCBkb21h aW4gbmV0d29yaw0KICAgbW9uaXRvcmluZyBjYW4gZGV0ZWN0IGlubmFwcHJvcHJpYXRlIHVzZSBv ZiBvZmZsaW5lIG9yIGVtZXJnZW5jeQ0KICAgZGVwbG95bWVudCBwcm9jZWR1cmVzIHdoZW4gdm91 Y2hlci1iYXNlZCBib290c3RyYXBwaW5nIGlzIG5vdCB1c2VkLg0KDQpUaGUgdXNlIG9mIFNIT1VM RCBhbmQgUkVDT01NRU5EIGFyZSBzdHJvbmcgaW5kaWNhdG9ycyBvZiBob3cgdGhpcyBzaG91bGQg YmUgZG9uZS4gQXMgbXVjaCBzbyBhcyBhIE1VU1QgInNlY3VyaXR5IHJlcXVpcmVtZW50cyB3ZSB3 cml0ZSBpbnRvIG91ciBzcGVjcywgd2UnbGwgaGF2ZSBubyBtZWFucyBvZiBlbmZvcmNlbWVudOKA nS4NCg0KU2luY2UgRWxpb3QgaGFzIGJyb3VnaHQgdXAgb3RoZXIgb3B0aW9ucyBsaWtlIGJlaW5n IGFibGUgdG8gcmVwbGFjZSB0aGUgTUFTQSB0cnVzdCBhbmNob3JzIG9yIHNvbWUgZm9ybSBvZiAg 4oCcc2VsZiBlbWl0dGVk4oCdIHZvdWNoZXIgaGVyZSBhcmUgdGhlIGN1cnJlbnQgdGhvdWdodHMg YWxvbmcgdGhvc2UgbGluZXM6DQoNCklmIG9uZSBwb3NzZXNzZWQgYSBub25jZWxlc3Mgdm91Y2hl ciB0aGVuIG9uZSBwb3NzZXNzZXMgYSBwZXJtYW5lbnQgdG9rZW4gdG8gZW5hYmxlIGJvb3RzdHJh cHBpbmcgb2YgdGhlIGRldmljZS4gVGhpcyBpcyB0aGUgdmVyeSBmaXJzdCBwb2ludCBpbiBzZWN0 aW9uIDcuMiBkaXNjdXNzZWQgYWJvdmU6DQoNCiAgIDEuICBUaGUgcGxlZGdlIE1VU1QgYWNjZXB0 IG5vbmNlbGVzcyB2b3VjaGVycy4gIFRoaXMgYWxsb3dzIGZvciBhIHVzZQ0KICAgICAgIGNhc2Ug d2hlcmUgdGhlIHJlZ2lzdHJhciBjYW4gbm90IGNvbm5lY3QgdG8gdGhlIE1BU0EgYXQgdGhlDQog ICAgICAgZGVwbG95bWVudCB0aW1lLiAgTG9nZ2luZyBhbmQgdmFsaWRpdHkgcGVyaW9kcyBhZGRy ZXNzIHRoZQ0KICAgICAgIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIHN1cHBvcnRpbmcgdGhl c2UgdXNlIGNhc2VzLg0KDQpUaGVyZSBhcmUgdHdvIHdheXMgdG8gbGV2ZXJhZ2UgdGhpcy4gUHJl ZG9taW5hdGVseSBoaXMgbWVhbnMgdGhhdCBhZnRlciBhIHNpbmdsZSBCUlNLSSBleGNoYW5nZSBh bnkgZG9tYWluIG93bmVyIGNhbiBvcHQgb3V0IG9mIGFueSBmdXR1cmUgQlJTS0kgc3R1ZmYgYW5k IHN0aWxsIGJlIGFibGUgdG8gKHJlKXBlcmZvcm0gb3Zlci10aGUtd2lyZSBib290c3RyYXBwaW5n ICh0aGlzIGlzIG9mIGNvdXJzZSBjYXB0dXJlZCBpbiB0aGUgYXVkaXQgbG9nKS4gQWRkaXRpb25h bGx5IHRoZSBwcml2YWN5IHByb3RlY3Rpb25zIG1lYW4gdGhhdCB0aGlzIHZvdWNoZXIgY2FuIGJl IHRpZWQgdG8gYSB0cmFuc2llbnQga2V5cGFpciB0aGF0IGNvdWxkIGJlIGRpc3RyaWJ1dGVkIHdp dGggdGhlIGRldmljZSBmb3IgcmVzYWxlLiBTbyB0aGlzIGNhbiBiZSBwYXNzZWQgb24gdG8gZW50 aXRpZXMgZnVydGhlciBkb3duIHRoZSBzdXBwbHkgY2hhaW4gb3IgZHVyaW5nIGEgcmVzYWxlIG9m IHRoZSBkZXZpY2UuDQoNClRoZXNlIHR3byBtZXRob2RzIGhpdCBhIGxhcmdlIHBlcmNlbnRhZ2Ug b2YgdXNlIGNhc2VzIGJlaW5nIGRpc2N1c3NlZCB3aGlsZSBtYWludGFpbmluZyB0aGUgYXVkaXQg bG9nLg0KDQotIG1heA0KDQpPbiBKdWwgMTIsIDIwMTksIGF0IDE6MjcgQU0sIEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBBZGFt DQoNCk9uIDEyIEp1bCAyMDE5LCBhdCAwMDoyNSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQoNClRoZSBzbWFsbGVzdCBjaGFu Z2UgdGhhdCB3b3VsZCBzYXRpc2Z5IG15IGNvbmNlcm4gd291bGQgYmUgYSBzdGF0ZW1lbnQgdGhh dCBzYXlzIHRoYXQgZGV2aWNlcyBjb25mb3JtYW50IHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNU IGNvbnRhaW4gYSBsb2NhbCBtZWFucyBvZiBib290c3RyYXBwaW5nIHRoYXQgZG9lcyBub3QgcmVs eSBvbiBhbnkgc3BlY2lmaWMgc2VydmVyIGJlaW5nIGF2YWlsYWJsZS4gQXMgd2l0aCB0aGUgc2Vj dXJpdHkgcmVxdWlyZW1lbnRzIHdlIHdyaXRlIGludG8gb3VyIHNwZWNzLCB3ZSdsbCBoYXZlIG5v IG1lYW5zIG9mIGVuZm9yY2VtZW50LiBCdXQgYXMgd2l0aCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1l bnRzIHdlIHdyaXRlIGludG8gb3VyIHNwZWNzLCB3ZSdsbCBnaXZlIGludGVyZXN0ZWQgcGFydGll cyBqdXN0IHRoYXQgbGl0dGxlIGJpdCBtb3JlIGxldmVyYWdlIHRoYXQgbWlnaHQgdGlwIHRoZSBz Y2FsZXMgdG93YXJkcyB0aGUgY29ycmVjdCBiZWhhdmlvci4NCg0KDQpJIHRoaW5rIHRoaXMgaXMg ZWFzaWx5IHBvc3NpYmxlIHdpdGhpbiB0aGUgcGFyYWRpZ20gb2YgdGhlIGRvY3VtZW50IGFmdGVy IHRoZSBkZXZpY2UgaGFzIGZpcnN0IGJlZW4gb25ib2FyZGVkLiBBdCB0aGlzIHN0YWdlLCBJIHdv dWxkIGFsc28gc3VnZ2VzdCB0aGF0IHRoZSBNVVNUIGJlIGEgU0hPVUxEIGZvciBhbm90aGVyIHJl YXNvbjogdGhlcmUgbWF5IGJlIGNhc2VzIHdoZXJlIGl0IGlzIGluIHRoZSBjdXN0b21lciBiZXN0 IGludGVyZXN0IHRvIHByZXZlbnQgb25ib2FyZGluZyBvZiBhIGRldmljZSBqdXN0IHRocm91Z2gg cHJvb2Ygb2YgcG9zc2Vzc2lvbi4gIEkgYW0gdGhpbmtpbmcgb2YgYW50aS10aGVmdCBtZWNoYW5p c21zLiAgSGF2aW5nIGEgZGlzY3Vzc2lvbiBvZiB0aGlzIGFuZCB0aGUgcmlza3Mgb2Ygbm90IGhh dmluZyBhbnkgb24tcHJlbSBtZXRob2QgZXZlciBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBhZGQu DQoNCkVsaW90DQoNCg== --_000_4BC524D004E74ACC8638453643961D15ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <62FFA54530491045A16AFB7F706B1CCF@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZZSSB3aGF0IHlvdSBhbGwgYXJlIGRpc2N1c3NpbmcgYXJl IHBvdGVudGlhbCBjaGFuZ2VzIHRvIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugb2YmbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0yMiNzZWN0aW9uLTcuMiIgY2xh c3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0 cmFwcGluZy1rZXlpbmZyYS0yMiNzZWN0aW9uLTcuMjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlByb2JhYmx5IHN0cmVuZ3RoZW5p bmcgdGhpcyBwYXJhZ3JhcGggZnJvbSBNQVkvU0hPVUxEIHRvIGEgTVVTVDo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7My4gJm5ic3A7VGhlIHBsZWRnZSBNQVkgaGF2ZSBhbiBvcGVyYXRpb25hbCBt b2RlIHdoZXJlIGl0IHNraXBzIHZvdWNoZXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7dmFsaWRhdGlvbiBvbmUgdGltZS4gJm5ic3A7Rm9yIGV4YW1wbGUg aWYgYSBwaHlzaWNhbCBidXR0b24gaXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZGVwcmVzc2VkIGR1cmluZyB0aGUgYm9vdHN0cmFwcGluZyBvcGVyYXRp b24uICZuYnNwO1RoaXMgY2FuIGJlIHVzZWZ1bDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpZiB0aGUgbWFudWZhY3R1cmVyIHNlcnZpY2UgaXMgdW5hdmFp bGFibGUuICZuYnNwO1RoaXMgYmVoYXZpb3IgU0hPVUxEPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIGF2YWlsYWJsZSB2aWEgbG9jYWwgY29uZmlndXJh dGlvbiBvciBwaHlzaWNhbCBwcmVzZW5jZSBtZXRob2RzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhzdWNoIGFzIHVzZSBvZiBhIHNlcmlhbC9jcmFmdCBj b25zb2xlKSB0byBlbnN1cmUgbmV3IGVudGl0aWVzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NhbiBhbHdheXMgYmUgZGVwbG95ZWQgZXZlbiB3aGVuIGF1 dG9ub21pYyBtZXRob2RzIGZhaWwuICZuYnNwO1RoaXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxsb3dzIGZvciB1bnNlY3VyZWQgaW1wcmludC48L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB0aGlzIGlzIGEgc3VnZ2VzdGVkIGNoYW5n ZSBwbGVhc2UgY29tbWVudCBvbiB0aGUgc3Vic2VxdWVudCBwYXJhZ3JhcGggd2hpY2ggcmVhZHM6 Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+SXQgaXMgUkVDT01NRU5ERUQgdGhhdCAmcXVvdDt0cnVzdCBvbiBm aXJzdCB1c2UmcXVvdDsgb3IgYW55IG1ldGhvZCBvZiBza2lwcGluZzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7dm91Y2hlciB2YWxpZGF0aW9uIChpbmNsdWRpbmcgdXNlIG9mIGNy YWZ0IHNlcmlhbCBjb25zb2xlKSBvbmx5IGJlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDthdmFpbGFibGUgaWYgaGFyZHdhcmUgYXNzaXN0ZWQgTmV0d29yayBFbmRwb2ludCBBc3Nl c3NtZW50IFtSRkM1MjA5XTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7aXMgc3Vw cG9ydGVkLiAmbmJzcDtUaGlzIHJlY29tbWVuZGF0aW9uIGVuc3VyZXMgdGhhdCBkb21haW4gbmV0 d29yazwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7bW9uaXRvcmluZyBjYW4gZGV0 ZWN0IGlubmFwcHJvcHJpYXRlIHVzZSBvZiBvZmZsaW5lIG9yIGVtZXJnZW5jeTwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ZGVwbG95bWVudCBwcm9jZWR1cmVzIHdoZW4gdm91Y2hl ci1iYXNlZCBib290c3RyYXBwaW5nIGlzIG5vdCB1c2VkLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSB1c2Ugb2YgU0hPVUxEIGFuZCBS RUNPTU1FTkQgYXJlIHN0cm9uZyBpbmRpY2F0b3JzIG9mIGhvdyB0aGlzIHNob3VsZCBiZSBkb25l LiBBcyBtdWNoIHNvIGFzIGEgTVVTVCAmcXVvdDtzZWN1cml0eSByZXF1aXJlbWVudHMgd2Ugd3Jp dGUgaW50byBvdXIgc3BlY3MsIHdlJ2xsIGhhdmUgbm8gbWVhbnMgb2YgZW5mb3JjZW1lbnTigJ0u PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5TaW5jZSBFbGlvdCBoYXMgYnJvdWdodCB1cCBvdGhlciBvcHRpb25zIGxpa2UgYmVpbmcgYWJs ZSB0byByZXBsYWNlIHRoZSBNQVNBIHRydXN0IGFuY2hvcnMgb3Igc29tZSBmb3JtIG9mICZuYnNw O+KAnHNlbGYgZW1pdHRlZOKAnSB2b3VjaGVyIGhlcmUgYXJlIHRoZSBjdXJyZW50IHRob3VnaHRz IGFsb25nIHRob3NlIGxpbmVzOiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCklmIG9uZSBwb3NzZXNzZWQgYSBub25jZWxlc3Mgdm91Y2hlciB0aGVuIG9u ZSBwb3NzZXNzZXMgYSBwZXJtYW5lbnQgdG9rZW4gdG8gZW5hYmxlIGJvb3RzdHJhcHBpbmcgb2Yg dGhlIGRldmljZS4gVGhpcyBpcyB0aGUgdmVyeSBmaXJzdCBwb2ludCBpbiBzZWN0aW9uIDcuMiBk aXNjdXNzZWQgYWJvdmU6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOzEuICZuYnNwO1RoZSBwbGVkZ2UgTVVT VCBhY2NlcHQgbm9uY2VsZXNzIHZvdWNoZXJzLiAmbmJzcDtUaGlzIGFsbG93cyBmb3IgYSB1c2U8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2FzZSB3aGVy ZSB0aGUgcmVnaXN0cmFyIGNhbiBub3QgY29ubmVjdCB0byB0aGUgTUFTQSBhdCB0aGU8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVwbG95bWVudCB0aW1l LiAmbmJzcDtMb2dnaW5nIGFuZCB2YWxpZGl0eSBwZXJpb2RzIGFkZHJlc3MgdGhlPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlY3VyaXR5IGNvbnNpZGVy YXRpb25zIG9mIHN1cHBvcnRpbmcgdGhlc2UgdXNlIGNhc2VzLjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBhcmUgdHdvIHdheXMgdG8gbGV2ZXJh Z2UgdGhpcy4gUHJlZG9taW5hdGVseSBoaXMgbWVhbnMgdGhhdCBhZnRlciBhIHNpbmdsZSBCUlNL SSBleGNoYW5nZSBhbnkgZG9tYWluIG93bmVyIGNhbiBvcHQgb3V0IG9mIGFueSBmdXR1cmUgQlJT S0kgc3R1ZmYgYW5kIHN0aWxsIGJlIGFibGUgdG8gKHJlKXBlcmZvcm0gb3Zlci10aGUtd2lyZSBi b290c3RyYXBwaW5nICh0aGlzIGlzIG9mIGNvdXJzZSBjYXB0dXJlZCBpbg0KIHRoZSBhdWRpdCBs b2cpLiBBZGRpdGlvbmFsbHkgdGhlIHByaXZhY3kgcHJvdGVjdGlvbnMgbWVhbiB0aGF0IHRoaXMg dm91Y2hlciBjYW4gYmUgdGllZCB0byBhIHRyYW5zaWVudCBrZXlwYWlyIHRoYXQgY291bGQgYmUg ZGlzdHJpYnV0ZWQgd2l0aCB0aGUgZGV2aWNlIGZvciByZXNhbGUuIFNvIHRoaXMgY2FuIGJlIHBh c3NlZCBvbiB0byBlbnRpdGllcyBmdXJ0aGVyIGRvd24gdGhlIHN1cHBseSBjaGFpbiBvciBkdXJp bmcgYSByZXNhbGUgb2YgdGhlDQogZGV2aWNlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlc2UgdHdvIG1ldGhvZHMgaGl0 IGEgbGFyZ2UgcGVyY2VudGFnZSBvZiB1c2UgY2FzZXMgYmVpbmcgZGlzY3Vzc2VkIHdoaWxlIG1h aW50YWluaW5nIHRoZSBhdWRpdCBsb2cuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIG1heDwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T24gSnVsIDEyLCAyMDE5LCBhdCAxOjI3IEFNLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWls dG86bGVhckBjaXNjby5jb20iIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkg QWRhbTxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEyIEp1bCAyMDE5LCBh dCAwMDoyNSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20i IGNsYXNzPSIiPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGUNCiBzbWFsbGVzdCBjaGFuZ2UgdGhhdCB3b3VsZCBzYXRp c2Z5IG15IGNvbmNlcm4gd291bGQgYmUgYSBzdGF0ZW1lbnQgdGhhdCBzYXlzIHRoYXQgZGV2aWNl cyBjb25mb3JtYW50IHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIGNvbnRhaW4gYSBsb2NhbCBt ZWFucyBvZiBib290c3RyYXBwaW5nIHRoYXQgZG9lcyBub3QgcmVseSBvbiBhbnkgc3BlY2lmaWMg c2VydmVyIGJlaW5nIGF2YWlsYWJsZS4gQXMgd2l0aCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz DQogd2Ugd3JpdGUgaW50byBvdXIgc3BlY3MsIHdlJ2xsIGhhdmUgbm8gbWVhbnMgb2YgZW5mb3Jj ZW1lbnQuIEJ1dCBhcyB3aXRoIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMgd2Ugd3JpdGUgaW50 byBvdXIgc3BlY3MsIHdlJ2xsIGdpdmUgaW50ZXJlc3RlZCBwYXJ0aWVzIGp1c3QgdGhhdCBsaXR0 bGUgYml0IG1vcmUgbGV2ZXJhZ2UgdGhhdCBtaWdodCB0aXAgdGhlIHNjYWxlcyB0b3dhcmRzIHRo ZSBjb3JyZWN0IGJlaGF2aW9yLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsgdGhpcyBpcyBlYXNpbHkgcG9z c2libGUgd2l0aGluIHRoZSBwYXJhZGlnbSBvZiB0aGUgZG9jdW1lbnQgYWZ0ZXIgdGhlIGRldmlj ZSBoYXMgZmlyc3QgYmVlbiBvbmJvYXJkZWQuIEF0IHRoaXMgc3RhZ2UsIEkgd291bGQgYWxzbyBz dWdnZXN0IHRoYXQgdGhlIE1VU1QgYmUgYSBTSE9VTEQgZm9yIGFub3RoZXIgcmVhc29uOiB0aGVy ZSBtYXkgYmUgY2FzZXMgd2hlcmUgaXQgaXMgaW4gdGhlIGN1c3RvbWVyIGJlc3QNCiBpbnRlcmVz dCB0byBwcmV2ZW50IG9uYm9hcmRpbmcgb2YgYSBkZXZpY2UganVzdCB0aHJvdWdoIHByb29mIG9m IHBvc3Nlc3Npb24uICZuYnNwO0kgYW0gdGhpbmtpbmcgb2YgYW50aS10aGVmdCBtZWNoYW5pc21z LiAmbmJzcDtIYXZpbmcgYSBkaXNjdXNzaW9uIG9mIHRoaXMgYW5kIHRoZSByaXNrcyBvZiBub3Qg aGF2aW5nIGFueSBvbi1wcmVtIG1ldGhvZCBldmVyIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIGFk ZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkVsaW90PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4BC524D004E74ACC8638453643961D15ciscocom_-- From nobody Fri Jul 12 14:07:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6A212030D; Fri, 12 Jul 2019 14:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 K85NZFdL36Ks; Fri, 12 Jul 2019 14:07:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767981202E0; Fri, 12 Jul 2019 14:07:31 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 4B97F3818F; Fri, 12 Jul 2019 17:05:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 24001B93; Fri, 12 Jul 2019 17:07:30 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 21:07:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max and Toerless, please search for your name. Adam Roach via Datatracker wrote: > =C2=A72.1 >> | +------v-------+ >> | | (5) Enroll |<---+ (non-error HTTP codes ) >> ^------------+ |\___/ (e.g. 201 'Retry-After') >> | Enroll +------+-------+ >> | Failure | > I can't work out what a "Retry-After" would mean in a "201 Created" r= esponse. > As noted above, section 5.6 of this document does indicate the use of= a > "Retry-After" header field with a 202 response, so I presume this dia= gram > should say 202? Thank you. It should say 202. > ---------------------------------------------------------------------= ------ > =C2=A75: >> BRSKI uses existing CMS message formats for existing EST operations. >> BRSKI uses JSON [RFC7159] for all new operations defined here, and >> voucher formats. > RFC 7159 has been obsoleted by RFC 8259. updated. > ---------------------------------------------------------------------= ------ > =C2=A75.2 >> The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header >> indicating the acceptable media type for the voucher response. The > Nit: ..."Accept" header field indicating... fixed. > ---------------------------------------------------------------------= ------ > =C2=A75.5 >> The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" >> header indicating the response media types that are acceptable. This > Nit: ..."Accept" header field indicating... fixed. >> field and appropriate 'Accept header' field values from the physical > Nit: ...'Accept header field' values... fixed. > ---------------------------------------------------------------------= ------ > =C2=A75.6 >> pledge would keep track of the appropriate Retry-After header values > Nit: "...Retry-After header field values..." fixed. >> desired type or using the desired algorithms (as indicated by the >> Accept: headers, and algorithms used in the signature) cannot be > Nit: "...Accept: header fields, ..." fixed. >> The voucher response format is as indicated in the submitted accept >> header or based on the MASA's prior understanding of proper format > Nit: "...Accept header field..." fixed. > ---------------------------------------------------------------------= ------ > =C2=A75.6 >> { >> "ietf-voucher:voucher": { >> "nonce": "62a2e7693d82fcda2624de58fb6722e5", >> "assertion": "logging" >> "pinned-domain-cert": "base64encodedvalue=3D=3D" >> "serial-number": "JADA123456789" >> } >> } > This JSON is syntactically invalid. Please run this example and all o= ther > instances of JSON in this document through a validation tool. I have moved all of our examples json into separate files in our directory = so that we can validate them better, and added the validation to the Makefile. I see that "FALSE" is not valid, but "false" is. Please note that we know we have to renumber the figures. In the appendix, we have examples of the JSON that is inside the CMS. These are from real examples, and we have the private keys so that implemen= tors can make sure they can produce the same outputs. The pinned-domain-cert has base64 in it, and it's more than 60 characters wide. I noticed it wasn't wrapped at all in -22, and just fixed that to be wrapped at 60 characters, but then, it isn't valid JSON, because it has LF in the "". I shall leave a note, but maybe you have a better suggestion= here. > ---------------------------------------------------------------------= ------ > =C2=A75.8: >> A MASA that returns a code 200 MAY also include a Location: header >> for future reference by the registrar. > Nit: "Location: header field" > Also, it's not 100% clear what the registrar would use this URI for. = Please > explain in the document. okay. > =C2=A75.8.1: >> Distribution of a large log is less than ideal. This structure can >> be optimized as follows: Nonced or Nonceless entries for the same >> domainID MAY be truncated from the log leaving only the single most > Nit: "truncate" means to shorten something by removing only the begin= ning or > only the end. I believe that you mean "omitted" (here and elsewhere i= n this > section). How about *abridged*? I also used omitted where it referred to a single ent= ry. > ---------------------------------------------------------------------= ------ > =C2=A76: >> In the BRSKI context, the EST "Content-Transfer-Encoding" header if >> present, SHOULD be ignored. This header does not need to included. > Nit: "...header field, if present..." > Nit: "This header field does not..." done. > ---------------------------------------------------------------------= ------ > =C2=A78.1: >> This document extends the definitions of "est" (so far defined via >> RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ >> well-known-uris.xhtml" registry as follows: >> >> o add /.well-known/est/requestvoucher (see Section 5.5 ) >> >> o add /.well-known/est/requestauditlog (see Section 5.7) > The .well-known registry does not contain sub-paths under the path > element that appears after ".well-known". I note that "est" has alrea= dy > been registered by RFC 7030. There are a bunch of ways this can be > handled, the easiest of which would be a request for the IANA to add > this RFC alongside RFC 7030 to the entry for "est." > More complex solutions would be selecting a different path than > "est", or establishing a separate sub-registry for paths under > the "est" well-known path. The response we got from Mark Nottingham was that this document would have to Updates: RFC7030. I'd rather not change the "est", but we could do that at this point. Max? > ---------------------------------------------------------------------= ------ > =C2=A78.4: >> Service Name: _brski-proxy > ... >> Service Name: _brski-registrar > You almost certainly don't want the service name to contain a leading > underscore. That is added as part of the DNS-SD resolution process, b= ut > not part of the service name itself. fixed. > ---------------------------------------------------------------------= ------ > Appendix B: >> For example, if the first >> Multicast DNS _bootstrapks._tcp.local response doesn't work then the >> second and third responses are tried. > I got a little lost here. Where is the "bootstrapks" service defined? > I don't see it defined in this document or registered at > https://www.iana.org/assignments/service-names-port-numbers/service-n= ames-port-numbers.xhtml?search=3Dbootstrapks Toerless, can you help here? I think that we renamed this. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0o9pEACgkQgItw+93Q 3WV4GAgAwN1N9ls+/GDb92f1Q3InZGtse8i2qrMmeRwdrATgHHNq523abbxQijic fYF1FvgWd0ArJGRRJwdU7W31SDOT+47XvsNvlU3hJgnS76yoORBWLxbKfei6ATQ+ tDvIk6zCq27rZ3H+tueGxN22FVHPfVtMaGWV0b2W/lSUUwZoAWQHi5vdKXDcsixG KhUd4r9LiAnize1IY0CFAm0kqf25u/tURzu0iyYftmASCRnu1jk19mTN1UHYpWK4 LKQmDwu4Lc3ZpgzXBgPnAW185jau1RN8HER2KH0Ix6B9qieboVdA6c8THnB0Y8HG mQORxWlxGcmhSDwQdQKCqgYCTQduUg== =Zstc -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 12 14:29:57 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C9120118; Fri, 12 Jul 2019 14:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 Thjv-oE3RSHF; Fri, 12 Jul 2019 14:29:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486961200D5; Fri, 12 Jul 2019 14:29:46 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6CLTb1j066530 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jul 2019 16:29:39 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562966980; bh=Vt1rvcaKBG4IQQtZHtBGthGoIiJu3XpIo20uwVJnt7g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PQ98f6M6NusLc/ZJKrmKTNnFp8/q4KAaSeDPiEsMuZGKgReSRKAClOLJBmOeyRdh5 FfAuVDrOQnYHmBqckyaonUoxHI3oEkrpACMy0DPnukXYQtmmknmfiBf9QMaSIjoYEV 1GQgS07xrEO2wZ3s+PQdqt814jQ8SuYEa1WKooPM= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <11332.1562965650@localhost> From: Adam Roach Message-ID: Date: Fri, 12 Jul 2019 16:29:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <11332.1562965650@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 21:29:48 -0000 Thanks for your reply. Responses to questions below. On 7/12/19 4:07 PM, Michael Richardson wrote: > > > --------------------------------------------------------------------------- > > > §5.6 > > >> { > >> "ietf-voucher:voucher": { > >> "nonce": "62a2e7693d82fcda2624de58fb6722e5", > >> "assertion": "logging" > >> "pinned-domain-cert": "base64encodedvalue==" > >> "serial-number": "JADA123456789" > >> } > >> } > > > This JSON is syntactically invalid. Please run this example and all other > > instances of JSON in this document through a validation tool. > > I have moved all of our examples json into separate files in our directory so > that we can validate them better, and added the validation to the Makefile. > I see that "FALSE" is not valid, but "false" is. > Please note that we know we have to renumber the figures. > > In the appendix, we have examples of the JSON that is inside the CMS. > These are from real examples, and we have the private keys so that implementors > can make sure they can produce the same outputs. > > The pinned-domain-cert has base64 in it, and it's more than 60 characters > wide. I noticed it wasn't wrapped at all in -22, and just fixed that to be > wrapped at 60 characters, but then, it isn't valid JSON, because it has > LF in the "". I shall leave a note, but maybe you have a better suggestion here. Your approach is fine. Many other protocols make the same kind of note when they need to break the syntax for RFC format purposes. The only other thing I've seen done is taking the whole message and bas64 encoding it, but that makes it less useful as an illustration in this case, so I would advise against it. > > §5.8.1: > > >> Distribution of a large log is less than ideal. This structure can > >> be optimized as follows: Nonced or Nonceless entries for the same > >> domainID MAY be truncated from the log leaving only the single most > > > Nit: "truncate" means to shorten something by removing only the beginning or > > only the end. I believe that you mean "omitted" (here and elsewhere in this > > section). > > How about*abridged*? I also used omitted where it referred to a single entry. "Abridged" seems a bit awkward: the *structure* is abridged, but the *entries* are omitted or elided or removed or excised or suppressed. You have two other queries, but they're addressed to other people. Let me know if you'd like my perspective on them. /a From nobody Sat Jul 13 11:41:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4B120157; Sat, 13 Jul 2019 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lUyM9Ki-xFMX; Sat, 13 Jul 2019 11:41:24 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189CE12017A; Sat, 13 Jul 2019 11:41:22 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id DD99F1F44D; Sat, 13 Jul 2019 18:41:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 205C02EB5; Sat, 13 Jul 2019 14:41:37 -0400 (EDT) From: Michael Richardson To: Magnus Westerlund cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-reply-to: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> References: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> Comments: In-reply-to Magnus Westerlund via Datatracker message dated "Thu, 11 Jul 2019 06:40:38 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain Date: Sat, 13 Jul 2019 14:41:37 -0400 Message-ID: <17539.1563043297@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 18:41:26 -0000 <#secure method=pgpmime mode=sign> Magnus Westerlund via Datatracker wrote: > A. This is really a discuss discuss. With to little time to dig into > the details it appears that this protocol is making i hack of its > interface towards the its transport. It appears to attempt to use an > HTTP rest interface, but then it is also have a lot of talking about > requirement for the TLS connection underlying the HTTP. So to > illustrate the issue I see here is what happens if one like to use QUIC > as the underlying transport for the rest interface rather than TCP/TLS? > So can this document achieve a clearer interface to the lower layers so > that it will be simpler to move the protocol to another underlying > version of the HTTP "transport"? Between the JRC (Registrar) and the MASA, we can support any HTTPS, including HTTP/2 with QUIC (with the 'normal' corporate firewall issue with UDP). Between the Pledge and the Registrar, we support any HTTPS that works over a single TCP connection. We can not support QUIC, since the Pledge is behind an intentionally limited proxy. We had some discussion about this a year or so ago, please see: https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4 You are certainly right: we have linkage between the TLS layer and the application layer, and we expect TLSClientCertificates and TLSServerCertificates to have meaning at the application layer. None of the connections could go through TLS "forced proxies" of the kind that are apparently common in Enterprises. I am open to suggestions on how to make the document clearer about how it interfaces to TLS. We have a sections: 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 > B. Section 5.6: > The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error > code when a problem occurs. > Referencing RFC 2616 that has been obsolete by RFC 7230 and > companions. I do note that there are no normative reference for that > part in this document. Fixed to 7230. Yes, that wasn't even a real reference, just a literal [RFC2616]. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jul 13 16:52:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3641C12001B; Sat, 13 Jul 2019 16:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 W6eG0w_HiACp; Sat, 13 Jul 2019 16:52:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7361200B2; Sat, 13 Jul 2019 16:51:59 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::aef]) by relay.sandelman.ca (Postfix) with ESMTPS id 40C501F44D; Sat, 13 Jul 2019 23:51:57 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E68852EB5; Sat, 13 Jul 2019 19:52:16 -0400 (EDT) From: Michael Richardson To: Alexey Melnikov cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-reply-to: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> Comments: In-reply-to Alexey Melnikov via Datatracker message dated "Thu, 11 Jul 2019 06:20:38 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29769.1563061936.1@dooku.sandelman.ca> Date: Sat, 13 Jul 2019 19:52:16 -0400 Message-ID: <29770.1563061936@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 23:52:03 -0000 Alexey Melnikov via Datatracker wrote: > 1) In Section 5: > o In the language of [RFC6125] this provides for a SERIALNUM-ID > category of identifier that can be included in a certificate and > therefore that can also be used for matching purposes. The > SERIALNUM-ID whitelist is collated according to manufacturer trust > anchor since serial numbers are not globally unique. > I think now you are just inventing things. Please define what exactly > SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed. https://github.com/anima-wg/anima-bootstrap/issues/132 I've asked Max to respond to this issue. > 2) In 5.6: > assertion: The method used to verify assertion. See Section 5.5.5. > Section 5.5.5 doesn't define syntax of this field in enough details to > implement. Can it contain one of the allowed values (like C enum)? I agree. We seem to have lost the definition. We insert an new section after 5.5.5 that explains this. https://github.com/anima-wg/anima-bootstrap/issues/133 > 3) In 5.8 > This is done with an HTTP GET using the operation path value of > "/.well-known/est/requestauditlog". > Here you say to use HTTP GET. > The registrar SHOULD HTTP POST the same registrar voucher-request as > But you only define how to use POST. I think the first "GET" is > supposed to be "POST". Fixed. > 4) In 5.8.1: > Format of different fields is not defined, so this is not > interoperable. We think that they are, as they are either repeats of what was in the voucher, or are integers. I guess we should resort to CDDL, which, since we started this document, is now a thing. https://github.com/anima-wg/anima-bootstrap/issues/134 > 5) In 8.1: > This document extends the definitions of "est" (so far defined via > RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ > well-known-uris.xhtml" registry as follows: > o add /.well-known/est/requestvoucher (see Section 5.5 ) > o add /.well-known/est/requestauditlog (see Section 5.7) > The .well-known URIs IANA registry doesn't list anything below the > first level (i.e. "est" in your case). So I think you really want to > have 2 IANA actions here: > a) Add the reference to this document as another reference for "est". > b) create a new registry of "est" URIs and add your 2 URIs above to it > and also populate other entries from the original EST RFC. The advice we got from the .well-known expert was that we should have this document Updates: RFC7030, and that the /est entry in the registry should say "RFC7030, RFCXXXX". Will this be enough rather than create a new registry? We think that no other /.well-known has a registry. Tell us which way to go. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > The first mention of HTTP 1.1 needs a Normative reference. Added. > 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices > Upon successfully validating a voucher artiface, a status telemetry > MUST be returned. See Section 5.7. > "artiface" is an unfortunate typo. I think you meant "artifact" here. Already fixed. > In 2.3.2: > As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in > this extension, including the scheme, iauthority, and ipath. As a > consideration to constrained systems, this MAY be reduced to only the > iauthority, in which case a scheme of "https://" and ipath of > "/.well-known/est" is to be assumed, as explained in section Section 5. > This is not a problem per se, but mixing absolute URIs and iauthority > in the same field makes me rather uncomfortable. Maybe you can define > ABNF for this field to make it crystally clear what is allowed > here. This would also avoid the need to use SHOULD and MAY above. Adam complained that we were using IRI inappropriately, so I'll wait for his response before changing this part. I don't think we need ABNF. Our goal is to put as short a thing in the certificate as possible. hostname:port is enough as the rest can be defaulted by the JRC. However, we observe the need to override the entire thing, particularly when doing interop testing, and so we want to be able to put the entire URL/IRI in. > In 2.3.2: "https" URI scheme needs a Normative reference. added reference to 7230, section 2.7.3 > 2.7. Cloud Registrar > If the pledge uses a well known URI for contacting a cloud registrar > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > authenticate service as described in [RFC6125]. > Just referencing RFC 6125 is not clear enough, as there are lots of > parameters that need to be specified: > a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards > allowed in any of these? We think it's up to the manufacturer to define a policy here. This section is an out for manufacturers that wish to provide some call-home mitigation for when the device is deployed where no ACP can be found. Maybe saying "well known URI" is causing a mis-understanding? > 4. Proxying details (Pledge - Proxy - Registrar) > In order to permit the proxy functionality to be implemented on the > maximum variety of devices the chosen mechanism SHOULD use the minimum > amount of state on the proxy device. > What does this mean? How can compliance with this SHOULD be evaluated? > I think you want to use lower case "should" here. Agreed. > In 5.7 (and a similar issue elsewhere): > { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail" > This is not valid JSON, this is not even valid pseudo-JSON. Please move > the comment: Already fixed, please see changes at: https://tinyurl.com/y2ex324x -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jul 13 17:13:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2369120143; Sat, 13 Jul 2019 17:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 z-qax3-bL4hx; Sat, 13 Jul 2019 17:13:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6C11200DB; Sat, 13 Jul 2019 17:13:47 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 21F761F44D; Sun, 14 Jul 2019 00:13:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DA26A2EB5; Sat, 13 Jul 2019 20:14:05 -0400 (EDT) From: Michael Richardson To: "The IESG" , anima@ietf.org In-reply-to: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> Comments: In-reply-to Alexey Melnikov via Datatracker message dated "Thu, 11 Jul 2019 06:20:38 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31580.1563063245.1@dooku.sandelman.ca> Date: Sat, 13 Jul 2019 20:14:05 -0400 Message-ID: <31581.1563063245@dooku.sandelman.ca> Archived-At: Subject: [Anima] a note on the rfcdiff for draft-ietf-anima-bootstrapping-keyinfra-22 DISCUSSes X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 00:13:50 -0000 If you visit the URL I gave to Eric: https://tinyurl.com/y2ex324x you will get an RFCDIFF that is rather wide. One of the fixes is for the very long JSON in the example in the appendix, so the left side is very very wide. The -22 version is very wide, which is rather annoying, so you have to scroll. I may post a -23 version with a fix for ONLY the wide JSON, so that a diff against -24 is more understandable. I can't do that until 22nd, but perhaps I'll stage it elsewhere until then. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jul 13 18:05:13 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A46120033; Sat, 13 Jul 2019 18:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FdmnqMUogcMu; Sat, 13 Jul 2019 18:05:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15EC120025; Sat, 13 Jul 2019 18:05:02 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::aef]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F5101F44D; Sun, 14 Jul 2019 01:04:59 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8239C2EB5; Sat, 13 Jul 2019 21:05:19 -0400 (EDT) From: Michael Richardson To: "The IESG" , anima@ietf.org In-reply-to: <31581.1563063245@dooku.sandelman.ca> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <31581.1563063245@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Sat, 13 Jul 2019 20:14:05 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3239.1563066319.1@dooku.sandelman.ca> Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2019 21:05:19 -0400 Message-ID: <3240.1563066319@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] a note on the rfcdiff for draft-ietf-anima-bootstrapping-keyinfra-22 DISCUSSes X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 01:05:05 -0000 This is an RFCDIFF that just wraps the very-long JSON: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-anima-bootstrapping-keyinfr= a-22&url2=3Dhttps://www.sandelman.ca/tmp/dtbootstrap-anima-keyinfra-22B.tx= t This is an rfcdiff from the already-wrapped JSON to the proposed -23 that includes all the changes from the various DISCUSSes: https://tinyurl.com/y2qhjwh8 This does not suffer from being very very wide. -- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- From nobody Sun Jul 14 03:36:50 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4730D120112; Sun, 14 Jul 2019 03:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 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 RewZ-pTaaXd4; Sun, 14 Jul 2019 03:36:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83881200F4; Sun, 14 Jul 2019 03:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11575; q=dns/txt; s=iport; t=1563100605; x=1564310205; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=mI+uE9ml40/7if5F3eTr8Ahwl5JtAH8HxPs8TUporys=; b=jofJfa4nVhHxWL8qGPs4+bPo9SuQQB5j5n9+H/AjhBptSTIDcul5cpd4 j83WUUFM30bcvaZr6TwOM+LTyWAFOdT+gnjN/ljdmznYXoVOKUPeheL++ pUoO4f7J/BHa0AwwkgcgLf6QjibUj1/ev2KM+hG8SetJ5VC0u1N0j24DE U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAIBStd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBZ4EZUQEgEiiEHIh7i3eSeoYDgXsCBwEBAQk?= =?us-ascii?q?DAQEYAQoMAQGBS4J1AoJ5NgcOAQMBAQQBAQIBBW2FPAyFSgEBAQECAQEBIUs?= =?us-ascii?q?LBQsLGCMHAgInMAYTgyIBgXsPD6l7gTKEMgGBFIRmEIE0AYFQiiWBf4ERJx+?= =?us-ascii?q?CTD6CYQEBgToRgyAygiYEjBCIYZVyCYIbgh+BDIMtiUSDcBuCLYclg2WKU5R?= =?us-ascii?q?9jH2DCwIEBgUCFYFXAi+BWDMaCBsVOyoBgkEJNYI6gmaFaIVBPQMwjheCUgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.63,490,1557187200"; d="asc'?scan'208,217";a="14285727" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2019 10:36:42 +0000 Received: from [10.61.168.132] ([10.61.168.132]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6EAae9r012979 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jul 2019 10:36:41 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_68973762-8F9C-4E63-AF85-C3F3343004A5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 14 Jul 2019 12:36:40 +0200 In-Reply-To: <17539.1563043297@dooku.sandelman.ca> Cc: Magnus Westerlund , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org To: Michael Richardson References: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> <17539.1563043297@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.168.132, [10.61.168.132] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 10:36:49 -0000 --Apple-Mail=_68973762-8F9C-4E63-AF85-C3F3343004A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_FF625F05-FFB1-4F5D-9603-35E3C02B2757" --Apple-Mail=_FF625F05-FFB1-4F5D-9603-35E3C02B2757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Michael, Magnus, I want to reinforce a point I made in that previous discussion about = pledges using BRSKI with H2 (and by extension QUIC). In this limited = case, both present needless overhead both in terms of dev costs and = COGS. H2 in particular, and in this particular case, introduces new dev = complexity because the provisional trust model used in BRSKI means that = you cannot make use of multiple channels within the transport until at = least the BRSKI transaction is complete. And once it=E2=80=99s = complete, and once EST is complete, the session is expected to = terminate(*). When BRSKI is in play, these transactions will happen = lock step. Eliot (*) Keep in mind these protocols are used to establish network access. = A good analogy is that they are the language used to communicate at the = gate with the security guard. Typically one prefers that conversation = to be short and to the point, so that one can get on with the business = at hand. > On 13 Jul 2019, at 20:41, Michael Richardson = wrote: >=20 >=20 > <#secure method=3Dpgpmime mode=3Dsign> >=20 > Magnus Westerlund via Datatracker wrote: >> A. This is really a discuss discuss. With to little time to dig into >> the details it appears that this protocol is making i hack of its >> interface towards the its transport. It appears to attempt to use an >> HTTP rest interface, but then it is also have a lot of talking about >> requirement for the TLS connection underlying the HTTP. So to >> illustrate the issue I see here is what happens if one like to use = QUIC >> as the underlying transport for the rest interface rather than = TCP/TLS? >> So can this document achieve a clearer interface to the lower layers = so >> that it will be simpler to move the protocol to another underlying >> version of the HTTP "transport"? >=20 > Between the JRC (Registrar) and the MASA, we can support any HTTPS, = including > HTTP/2 with QUIC (with the 'normal' corporate firewall issue with = UDP). >=20 > Between the Pledge and the Registrar, we support any HTTPS that works = over a > single TCP connection. We can not support QUIC, since the Pledge is = behind > an intentionally limited proxy. We had some discussion about this a = year or > so ago, please see: > = https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4 >=20 > You are certainly right: we have linkage between the TLS layer and the > application layer, and we expect TLSClientCertificates and > TLSServerCertificates to have meaning at the application layer. >=20 > None of the connections could go through TLS "forced proxies" of the = kind > that are apparently common in Enterprises. >=20 > I am open to suggestions on how to make the document clearer about how = it > interfaces to TLS. We have a sections: > 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 > 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 >=20 >=20 >=20 >> B. Section 5.6: >=20 >> The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] = error >> code when a problem occurs. >=20 >> Referencing RFC 2616 that has been obsolete by RFC 7230 and >> companions. I do note that there are no normative reference for that >> part in this document. >=20 > Fixed to 7230. > Yes, that wasn't even a real reference, just a literal [RFC2616]. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_FF625F05-FFB1-4F5D-9603-35E3C02B2757 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Michael, Magnus,

I want to reinforce a point I made in that previous = discussion about pledges using BRSKI with H2 (and by = extension QUIC).  In this limited case, both present needless = overhead both in terms of dev costs and COGS.  H2 in particular, = and in this particular case, introduces new dev complexity because the = provisional trust model used in BRSKI means that you cannot make use of = multiple channels within the transport until at least the BRSKI = transaction is complete.  And once it=E2=80=99s complete, and once = EST is complete, the session is expected to terminate(*).  When = BRSKI is in play, these transactions will happen lock step.

Eliot

(*) Keep in mind these = protocols are used to establish network access.  A good analogy is = that they are the language used to communicate at the gate with the = security guard.  Typically one prefers that conversation to be = short and to the point, so that one can get on with the business at = hand.


On 13 = Jul 2019, at 20:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


<#secure method=3Dpgpmime mode=3Dsign>

Magnus Westerlund via Datatracker <noreply@ietf.org> = wrote:
A. This is = really a discuss discuss. With to little time to dig into
the details it appears that this protocol is making i hack of = its
interface towards the its transport. It appears to = attempt to use an
HTTP rest interface, but then it is also = have a lot of talking about
requirement for the TLS = connection underlying the HTTP. So to
illustrate the issue = I see here is what happens if one like to use QUIC
as the = underlying transport for the rest interface rather than TCP/TLS?
So can this document achieve a clearer interface to the lower = layers so
that it will be simpler to move the protocol to = another underlying
version of the HTTP "transport"?

Between the JRC (Registrar) and = the MASA, we can support any HTTPS, including
HTTP/2 with = QUIC (with the 'normal' corporate firewall issue with UDP).

Between the Pledge and the Registrar, we = support any HTTPS that works over a
single TCP connection. =  We can not support QUIC, since the Pledge is behind
an= intentionally limited proxy.  We had some discussion about this a = year or
so ago, please see:
 https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0z= fuzn8uw4

You are certainly right: we = have linkage between the TLS layer and the
application = layer, and we expect TLSClientCertificates and
TLSServerCertificates to have meaning at the application = layer.

None of the connections could go = through TLS "forced proxies" of the kind
that are = apparently common in Enterprises.

I am open = to suggestions on how to make the document clearer about how it
interfaces to TLS.  We have a sections:
=    5.1.  BRSKI-EST TLS establishment details . . . . = . . . . . . .  36
   5.4. =  BRSKI-MASA TLS establishment details  . . . . . . . . . . =  38



B. Section 5.6:

The server MUST answer with a suitable 4xx or 5xx HTTP = [RFC2616] error
code when a problem occurs.

Referencing RFC 2616 that has been obsolete by RFC 7230 = and
companions. I do note that there are no normative = reference for that
part in this document.

Fixed to 7230.
Yes, = that wasn't even a real reference, just a literal [RFC2616].

--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
] =   Michael Richardson, Sandelman Software Works =        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/ =        |   ruby on rails =    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-


_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

= --Apple-Mail=_FF625F05-FFB1-4F5D-9603-35E3C02B2757-- --Apple-Mail=_68973762-8F9C-4E63-AF85-C3F3343004A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSsFuAAKCRBugA9nE248 uDTyAKCBKGskoQ3HJrbDJs4iXlf7LIrGJgCg6P3d2SDr3MEHrC4dRE+0LgW+a+U= =YWob -----END PGP SIGNATURE----- --Apple-Mail=_68973762-8F9C-4E63-AF85-C3F3343004A5-- From nobody Sun Jul 14 14:33:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187C5120294; Sun, 14 Jul 2019 14:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T0XcerLWXYDL; Sun, 14 Jul 2019 14:33:07 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59FD12019D; Sun, 14 Jul 2019 14:33:06 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BF431F44C; Sun, 14 Jul 2019 21:33:04 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id AF7251301; Sun, 14 Jul 2019 17:33:22 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org In-reply-to: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> Comments: In-reply-to Eliot Lear message dated "Thu, 11 Jul 2019 23:49:13 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 14 Jul 2019 17:33:22 -0400 Message-ID: <8869.1563140002@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:33:09 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Whether such a voucher would be pinned is something we do not have to > specify, with the risks of it not being pinned being born by the owne= r. I beg to differ! I think that the security properties are vastly different. It's why we decided when creating RFC8366 not to do bearer tokens.=20=20 We simply didn't think we were competent enough to specify it tightly enough to not become a security disaster. An unpinned voucher is some kind of bearer token, and if disclosed has significant operational risk. As such, keeping it around/online is a serio= us issue. A voucher pinned to the public part of a keypair whose private key is kept offline (to be turned over to a new owner) is different because there are potentially far fewer things to keep private. Worse case, it's perhaps the same, I would agree. The bigger problem is that I don't see a way to define such an artifact in a timely fashion, nor do I know which WG we'd do it in. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0rn6IACgkQlUzhVv38 QpAzcAf/cvSCOFRllt2u0alHd0fvXZPXkdY2zIlgkhNbBfBf0Xn6e4j+h/2D+Czb 2YbD06relmwEOjrn7JLUl4DO/O97iaFXJkvWeHkbWv2NNG/GuBgrjOINmxkfj07Q owZYn4YcvVlXJhloSUuMCv3cCQ14slZO/RnzsN26qFHFRMB6Z6UytOqldMumR+Ri u5/K9PCfm1OU0IuX0IBjHJoeByvtwQK4Ogr6k4jssK9frso7mbwnR6+Ep3cU6Rkl XGNEhNe9hSG+h7/ePr8609Zi4lN5AaA3qKH++wjBAh0b5BIB/433ju1hGHwE2boh I1v6tByKbRuv79QvYTJTlVfBcPl89g== =lA3t -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 14 15:19:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1A2120189; Sun, 14 Jul 2019 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QPgtY8edVoS3; Sun, 14 Jul 2019 15:18:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E851200B4; Sun, 14 Jul 2019 15:18:52 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id BB43F3818E; Sun, 14 Jul 2019 18:18:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 36B24FE2; Sat, 13 Jul 2019 11:13:32 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org In-Reply-To: <20190711214847.GA16418@kduck.mit.edu> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <20190711214847.GA16418@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 22:18:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot> I think the simplest way to address the bulk of both Adam=E2=80=99s = and Eliot> Warren=E2=80=99s concern is to require the device to emit via whatev= er Eliot> management interface exists, upon request, a voucher that it has Eliot> signed with its own iDevID. It would have to be nonceless with Eliot> perhaps a long expiry, and that would cover a number of other use Eliot> cases as well. That way if the manufacturer goes out of business, or Eliot> if the owner wants to transfer the device without manufacturer Eliot> consent, there is a way forward. Benjamin Kaduk wrote: > An interesting thought. Would there be a way (or a need) to usefully > audit such voucher issuance? The vendor would be unable to provide any record of them being issued. The device could provide an audit log. Perhaps we could use some kind of merkle tree such that every such voucher had a record of all previous ones, going back to the original MASA issue voucher. I had originally considered this to be the right way to do resale, but many others thought it too complex. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0p9RsACgkQgItw+93Q 3WXkuwf/d86mNl8+RnFxMYx+vHfNfGbBM2gcmtz6+OY+ziHYJpdrSO7AwL90ZD1i DlbCOmZwYuOaae5YA3EUNCGohiB1fLBty7m9lXIFc5KJqncmqzUyB3HJRmVMz+9J q9TH9k4vL3P3u+G8ClGS6yqLE+XHJ68/pBkow9MkGDNVOWMZFWLed3iN4c7N227/ DtGLzJ5GeZrSG8sawsO3r4uHC10t1HiwK8upvsUD1Tx+BJxq5jk74/k40DWK6dOI 8xsatsABM0OtEqDZzRN2aJnkaHBC11/mMUIGdhT18SBoPbXjL0TLvrfGqJDzrdVp Yek2uZc7aKWneexKr4p0fh/9menbVw== =y462 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 14 15:49:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDABA120158; Sun, 14 Jul 2019 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 x5OUEdhRL1qJ; Sun, 14 Jul 2019 15:48:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BD712006B; Sun, 14 Jul 2019 15:48:54 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 765A33818E; Sun, 14 Jul 2019 18:48:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB44FF32; Sat, 13 Jul 2019 11:10:27 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Adam Roach , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 22:48:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > I think the simplest way to address the bulk of both Adam=E2=80=99s a= nd > Warren=E2=80=99s concern is to require the device to emit via whatever > management interface exists, upon request, a voucher that it has sign= ed > with its own iDevID. It would have to be nonceless with perhaps a lo= ng > expiry, and that would cover a number of other use cases as well. Th= at > way if the manufacturer goes out of business, or if the owner wants to > transfer the device without manufacturer consent, there is a way > forward. 1) would it have a pinned-domain-cert for the new owner, or would it be some kind of wildcard/bearer voucher? 2) what would the management interface be, specifically, how would it be secured? This would seem to cover the case where there is an orderly sale of equipme= nt From=20an owner who is still in business to a new owner who is ready to rec= eive the device. In my experience buying used routing equipment, this is never the case. The best case is that equipment was removed from active service 6 to 10 months previously, stored somewhere until it was certain that no spares wou= ld be required, and then sold on eBay directly to the buyer. Creating this new voucher would require that the sellor spin the systems up, hook them back onto some management interface (which effectively means going through the onboarding process again, since their IP addresses will be wron= g, having been replaced), and then getting a voucher issued for the buyor's domainID. Is this ridiculous? No. Knowing that the systems boot (and haven't rotted), and knowing that the old configurations have correctly wip= ed is pretty good hygiene. Often the systems are purchased by a used equipment broker, and having the broker issue an intermediate (could be time limited) voucher to themselves would be reasonable as they take the systems into their inventory. In larg= er sales, the broker could provide personnel to do the spin-up at the sellor's location. The sellor *could* generate that voucher themselves before the device is taken offline, linking the voucher to a newly generated domain owner keypair. This effectively is now a bearer voucher. At which point one cou= ld consider some other kind of existing technology: a TLS session resumption ticket (issued by the BRSKI client to the Registrar) might make more sense. It has all the properties of a bearer voucher, and all the risks, but is well established mechanism. I would be happy to start a draft that explained this process. It's something that I wish we have a SEC-AREA BRSKI WG to make sure we get this right. In the worst case, the reason the equipment is being sold is because the sellor went into bankruptcy. There is no sellor Registrar to invoke this API. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0p9GMACgkQgItw+93Q 3WXT9QgAhZ1hBz75mz2Bc+8SvxaTMV/hNosOrCHjHtSYb2MIYFp/5PY6sN+erZLR 7Y27qq7VLnhQFHw6z0HPzDgi67DDpadHU9yDswKbqvotk0wIELlPmeiJX7SjhpwB S7fdlLM7OyeNEx9Gt2jECRZ1Zx3ASeSm43YYCgynvwYRNDwz32lfAW9Q73rJQIAU zOUGSltMY6CW4dCjLpGgOzyd1etUzuAhlaMnATkjkjO/BTWW/pXI8noKcsjEtj/9 vS5v6+GqEtMD9cyXD3xUYOGOpfA4m7uNy4EwbeWs33YU/Cq671bZzciwCsNmrLKs yRgvjfMaMesRWSV3GW/EHdsQxWlOSA== =NBti -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 14 21:45:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F313120046; Sun, 14 Jul 2019 21:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 GuG4VBcqGBgK; Sun, 14 Jul 2019 21:45:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46441120020; Sun, 14 Jul 2019 21:45:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45n9tx1NCrzkYjv; Sun, 14 Jul 2019 21:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563165913; bh=MgMDT5FZxHILjeJdZI02Tpv0xsDsPhiVGZ/iHET+ohM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fOHqmIeMXb6Igg3oWloKHlm/qB4DlSruBBxABIvhhqxNDmEDtcuG2Wwd+uNcQStue KLO9x7b+kdNom82rLjGc8wNEiHER1arUv7geZ7k68hMCLM41vpOinkVWCqXRJWSjlR fSoUHBcUtiDevD45wmjQytVDAxJhp3Bz1uu53O2E= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45n9tv4Hf9zkXWj; Sun, 14 Jul 2019 21:45:11 -0700 (PDT) To: Michael Richardson , Eliot Lear Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> From: "Joel M. Halpern" Message-ID: Date: Mon, 15 Jul 2019 00:45:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <8869.1563140002@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 04:45:15 -0000 I presume I am missing something basic. I have tried to follow this discussion, as it seems to be about a critical aspect of whether the BRSKI work is acceptable. I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. Have I got the wrong end of the stick? Joel On 7/14/2019 5:33 PM, Michael Richardson wrote: > > Eliot Lear wrote: > > Whether such a voucher would be pinned is something we do not have to > > specify, with the risks of it not being pinned being born by the owner. > > I beg to differ! > I think that the security properties are vastly different. > It's why we decided when creating RFC8366 not to do bearer tokens. > We simply didn't think we were competent enough to specify it tightly enough > to not become a security disaster. > > An unpinned voucher is some kind of bearer token, and if disclosed has > significant operational risk. As such, keeping it around/online is a serious > issue. > > A voucher pinned to the public part of a keypair whose private key is > kept offline (to be turned over to a new owner) is different because there > are potentially far fewer things to keep private. Worse case, it's perhaps > the same, I would agree. > > The bigger problem is that I don't see a way to define such an artifact in a > timely fashion, nor do I know which WG we'd do it in. > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 15 00:40:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079CC120074; Mon, 15 Jul 2019 00:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 lLBsuEx5gfcZ; Mon, 15 Jul 2019 00:40:00 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FB212001E; Mon, 15 Jul 2019 00:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3594; q=dns/txt; s=iport; t=1563176400; x=1564386000; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8Uh+VkmV/7Yb8JKBiokqGARi6F3tBiejJbCQzGXnlLc=; b=OrNUdN9xrRLJHY/1FK+g6HRiIvPq6Ffyo0l0J610VNfO86WXhym0F/4o mzKyGyH1W+Dw9YAXuyEmKibeblhnQmAXASnTwOsHLhCp12k/qRCxi7JaQ LbA6dM7ZWhZwRHGcM3Fl4Hi/dZ/MbEVbSbmqM9FHfIC5GRsPCKpCqum3J k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAgLSxd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGDUQEgEiiEHIh7i1IlmH2BewIHAQEBCQMBAS8?= =?us-ascii?q?BAYRAAoJ9NQgOAQMBAQQBAQIBBW2FSIVKAQEBAQIBI1YFCwsYIwcCAlcGCgm?= =?us-ascii?q?DIgGBew+qKIEyhUeEYxCBNAGBUIolgX+BEScME4JMPodOMoImBIw4HIgdlXI?= =?us-ascii?q?JghuCH4EMjBkFhEMbk3iEEqF6gwsCBAYFAhWBUQE2gVgzGggbFWUBgkE+gjq?= =?us-ascii?q?ODz0DMJArAQE?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="asc'?scan'208";a="14252660" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 07:39:58 +0000 Received: from ams3-vpn-dhcp3718.cisco.com (ams3-vpn-dhcp3718.cisco.com [10.61.78.134]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6F7dvvp021845 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 07:39:57 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A3B84DC0-D8D0-458E-801A-6E2555B0865E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 09:39:56 +0200 In-Reply-To: <1692.1563030627@localhost> Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org To: Michael Richardson References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.78.134, ams3-vpn-dhcp3718.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 07:40:03 -0000 --Apple-Mail=_A3B84DC0-D8D0-458E-801A-6E2555B0865E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Jul 2019, at 17:10, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> I think the simplest way to address the bulk of both Adam=E2=80=99s = and >> Warren=E2=80=99s concern is to require the device to emit via = whatever >> management interface exists, upon request, a voucher that it has = signed >> with its own iDevID. It would have to be nonceless with perhaps a = long >> expiry, and that would cover a number of other use cases as well. = That >> way if the manufacturer goes out of business, or if the owner wants = to >> transfer the device without manufacturer consent, there is a way >> forward. >=20 > 1) would it have a pinned-domain-cert for the new owner, or would it = be > some kind of wildcard/bearer voucher? Again, I think this is a matter for the seller, and also a matter for = the seller as to when the voucher is generated, so that it doesn=E2=80=99t= need to lie around. I was also thinking that this would be the sort of = thing that could be printed out, either in a QR or OCR form, if = necessary. >=20 > 2) what would the management interface be, specifically, how would it = be > secured? The reason I mentioned CIP and Profinet in a previous message is that = once the device is bootstrapped, if it has a management interface, that = is what should be used. Adding new services on a device is undesirable. = This covers the case when the manufacturer becomes unavailable. = However, it should be viewed as a backstop. See below. >=20 > This would seem to cover the case where there is an orderly sale of = equipment > =46rom an owner who is still in business to a new owner who is ready = to receive > the device. In my experience buying used routing equipment, this is = never > the case. Unless the owner printed out such a label in advance. The point is that = the mechanism could reasonably be used. Many credentials are written on = your wireless devices right now. This give you the option for that not = to be the case (people needn=E2=80=99t worry about Siemens, Rockwell, = JCI, Honeywell, or Schneider Electric going out of business anytime = soon, for instance - they may feel differently about Joe=E2=80=99s Tool = and Die). Another way to look at this would be to for the manufacturer to ping the = owner periodically to reconfirm ownership. If the owner fails to = respond, allow another owner to transfer the device. Or=E2=80=A6 simply = ping the owner when a transfer request is made. But these require that = the MASA be present. To Adam=E2=80=99s broader point, there are at least several ways to = approach this. We can leave it to the vendor to decide which is = correct, and we can continue to look to standardize ideas such as the = one Michael had in the message I=E2=80=99m replying to now. Eliot --Apple-Mail=_A3B84DC0-D8D0-458E-801A-6E2555B0865E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXSwtzAAKCRBugA9nE248 uAnlAKDAfNg92j2ZlOkvXdLPXkXMOdCRnACgxrWltuGi8ztwnf4VXK01tGmKrv4= =yigz -----END PGP SIGNATURE----- --Apple-Mail=_A3B84DC0-D8D0-458E-801A-6E2555B0865E-- From nobody Mon Jul 15 02:41:58 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A412006E; Mon, 15 Jul 2019 02:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 9hYInAUPDVjc; Mon, 15 Jul 2019 02:41:53 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150048.outbound.protection.outlook.com [40.107.15.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDAD120048; Mon, 15 Jul 2019 02:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ivKZacgu8YTWyQZ7eF0rYW2l8TUTYcuMkbO4jdk2X6uIpv/RCObvoX/UdMrt+N3jjWkDmsK6SETpeAuR/eysqaJmlTaM/89DALPJLQyNfV6lr4O1TsHRoKZgWnYKkeIybf/pFtYGJjnk9VYxFiQ3hl8+JrJS0MiIK3JDyqivFBjGxA8hyUOdSavyGmDDESNC66b9/bugSXD8w3oaolfBMHNuVj4GO3Vnq5rz+73D7t3Z6bYIZRJGSJqjqmtt5gTBzSgtjwdMR0HqS1JZkKRaocdt6kd60I1HXfSQJP3rx84juztDb/ZT2PRiRHZeyLRMOCyiHQoehSKlbG/Gjq/bZw== 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=YOequ9GFO4OKKfyQbB6X+3p2IdSgGlIteq5Nb8HC2QI=; b=bMvCz2t4MyjBM89K2Da/kr0YdiGM5QVdwFgvUoYdkCzP5xFNUHHL2FLQwBtXEFalKlSCBg8LRw3W22mYQ4g5VOIQXj0/GE/wIouZPH6vwiVFcuSSP/wcLroleZsHXUC98SGd3d6EUjKiZAOuHElgKDifcaQE/FV/yJNKa+yaETNG898nFG+czq+UJDMsoXnPQjiYla4/fzo9s0GnHA54DJS9inrSGyhyYBSK6XkwTM+/FBU9wSNp0R5CmGhpmoZiM+guhi+d3r07AUOa+aZMzVisOJVoZJWz4StpgqtJa1ZkZdij6muQ1m2OZC/QF2aRufvjURTGAb9+fI6oiJAAgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YOequ9GFO4OKKfyQbB6X+3p2IdSgGlIteq5Nb8HC2QI=; b=AeOnMv4QmBtE5hKZWdgxDz8qC7OTeJFmB5hS4W41+f4ztN6XtzdCZIEn189nlbZjC0dXEBZpcgVXNQ8UoerKbwScK1JZ+FYz5mGcGkLkwGNpfiLUUOxuaTAb6uW+oJSnEidLxFXGCP5cEE2Cjloc9sz4VXPyuUFc8np0+juCXyg= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2299.eurprd07.prod.outlook.com (10.168.126.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.7; Mon, 15 Jul 2019 09:41:49 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::3418:2814:2ee2:a22b%4]) with mapi id 15.20.2094.009; Mon, 15 Jul 2019 09:41:49 +0000 From: Magnus Westerlund To: "mcr+ietf@sandelman.ca" , "lear@cisco.com" CC: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "iesg@ietf.org" , "anima@ietf.org" , "anima-chairs@ietf.org" , "tte+ietf@cs.fau.de" Thread-Topic: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS) Thread-Index: AQHVN+5KUsbp8tUGhUekqxsnMkzX6qbI5VeAgAEK1wCAAYMAAA== Date: Mon, 15 Jul 2019 09:41:49 +0000 Message-ID: References: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com> <17539.1563043297@dooku.sandelman.ca> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84f8f666-7a2c-4b85-7ed0-08d70908a92f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2299; x-ms-traffictypediagnostic: HE1PR0701MB2299: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(376002)(39860400002)(346002)(199004)(189003)(8676002)(8936002)(81166006)(81156014)(6436002)(2906002)(118296001)(7736002)(186003)(53936002)(36756003)(6246003)(66946007)(66616009)(66476007)(6306002)(6512007)(66066001)(2501003)(478600001)(86362001)(6486002)(25786009)(229853002)(5660300002)(71200400001)(4326008)(71190400001)(256004)(26005)(14444005)(68736007)(2616005)(76176011)(110136005)(446003)(11346002)(486006)(54906003)(44832011)(3846002)(6116002)(99286004)(476003)(6506007)(102836004)(53546011)(64756008)(66446008)(76116006)(66556008)(14454004)(99936001)(316002)(966005)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2299; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0bRhFuCLN2hsIclsoPxHS5yFTgKpMMEPlLhkHBgRXZJ/SmzQmQlEE45SHvz7fe56xf9G/Fj5aaEp4lgx4STzZ6l9iNTzIy3rNKeXWz+SF+Uy5rMimV2CWmmg1wVPSb0FzUA0gLfRIshiljbRLunFSz4IX4fkRlWwFDVqGXAjb8r/AgR1akBZe19Z0YFhhiScf7ml87bZUHOJvEIiAdsgcxb4bifkfwI8nRJMPhKhIR5ERhGHijR1lZ4nKjbgTwCETT/G+HnfxLK+xJVEXYdhwWGZjJd7Xe3IYfaURmPVujNQWX0A77v152MtAdp7P4pndQQZR7LNahANxaiG51zVwmiDsXuRauw/0ZpqYUcyY2HUIEI+HSradM6Ge6Dcxnp4lSuIEKkqnkza7TwBSrS9Ry6Uq0UJjL2+b3NvXuQLdCc= Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-v3l51HeEnSBUiCnj654T" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84f8f666-7a2c-4b85-7ed0-08d70908a92f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 09:41:49.7835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2299 Archived-At: Subject: Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 09:41:56 -0000 --=-v3l51HeEnSBUiCnj654T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I will remove my discuss. As long as you have good reasons to have dependenecies on a particular version of HTTP and TLS and transport protocol that is fine with me. Just ensure that it is clear for the different type of interactions what is the actual requirement. And if there are no reason for having a specific dependency, then ensure that is clear and that you still put in recommended version for interoperability.=20 Cheers Magnus On Sun, 2019-07-14 at 12:36 +0200, Eliot Lear wrote: > Michael, Magnus, >=20 > I want to reinforce a point I made in that previous discussion about > pledges using BRSKI with H2 (and by extension QUIC). In this limited > case, both present needless overhead both in terms of dev costs and > COGS. H2 in particular, and in this particular case, introduces new > dev complexity because the provisional trust model used in BRSKI > means that you cannot make use of multiple channels within the > transport until at least the BRSKI transaction is complete. And once > it=E2=80=99s complete, and once EST is complete, the session is expected = to > terminate(*). When BRSKI is in play, these transactions will happen > lock step. >=20 > Eliot >=20 > (*) Keep in mind these protocols are used to establish network > access. A good analogy is that they are the language used to > communicate at the gate with the security guard. Typically one > prefers that conversation to be short and to the point, so that one > can get on with the business at hand. >=20 >=20 > > On 13 Jul 2019, at 20:41, Michael Richardson > > wrote: > >=20 > >=20 > > <#secure method=3Dpgpmime mode=3Dsign> > >=20 > > Magnus Westerlund via Datatracker wrote: > > > A. This is really a discuss discuss. With to little time to dig > > > into > > > the details it appears that this protocol is making i hack of its > > > interface towards the its transport. It appears to attempt to use > > > an > > > HTTP rest interface, but then it is also have a lot of talking > > > about > > > requirement for the TLS connection underlying the HTTP. So to > > > illustrate the issue I see here is what happens if one like to > > > use QUIC > > > as the underlying transport for the rest interface rather than > > > TCP/TLS? > > > So can this document achieve a clearer interface to the lower > > > layers so > > > that it will be simpler to move the protocol to another > > > underlying > > > version of the HTTP "transport"? > >=20 > > Between the JRC (Registrar) and the MASA, we can support any HTTPS, > > including > > HTTP/2 with QUIC (with the 'normal' corporate firewall issue with > > UDP). > >=20 > > Between the Pledge and the Registrar, we support any HTTPS that > > works over a > > single TCP connection. We can not support QUIC, since the Pledge > > is behind > > an intentionally limited proxy. We had some discussion about this > > a year or > > so ago, please see: > > =20 > > https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4 > >=20 > > You are certainly right: we have linkage between the TLS layer and > > the > > application layer, and we expect TLSClientCertificates and > > TLSServerCertificates to have meaning at the application layer. > >=20 > > None of the connections could go through TLS "forced proxies" of > > the kind > > that are apparently common in Enterprises. > >=20 > > I am open to suggestions on how to make the document clearer about > > how it > > interfaces to TLS. We have a sections: > > 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . > > 36 > > 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . > > 38 > >=20 > >=20 > >=20 > > > B. Section 5.6: > > > The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] > > > error > > > code when a problem occurs. > > > Referencing RFC 2616 that has been obsolete by RFC 7230 and > > > companions. I do note that there are no normative reference for > > > that > > > part in this document. > >=20 > > Fixed to 7230. > > Yes, that wasn't even a real reference, just a literal [RFC2616]. > >=20 > > -- > > ] Never tell me the odds! | ipv6 mesh > > networks [ > > ] Michael Richardson, Sandelman Software Works | network > > architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > > rails [ > >=20 > >=20 > > -- > > Michael Richardson , Sandelman Software > > Works > > -=3D IPv6 IoT consulting =3D- > >=20 > >=20 > >=20 > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-v3l51HeEnSBUiCnj654T Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDcxNTA5NDE0OFowLwYJKoZIhvcN AQkEMSIEIAKx1HqGA6dLyx+itEwRxvvR2R6lMYd7MFhDOQC4TseTMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEALTM68Wj5oLqP zpjM6mMNlajt9RJeBtwhWfxym44GHxR4QKlfDNvecWBXrrhfsJfSof8TKf2SkCKReK9K1TA1on3G En+ZjxGRsjkyFWzW3lofEzb9f17wvpJl1oSvHsH1s650RyPwVRAygZd3ZW91K4CRE8x4oGRzEUDu U8Ls1O3y8jxD8fGtKmmaB4JmH5pjU2tKgyKWJAo5LsTUfL+P70e6TrHK67RQzhie/ge4aTrCnOjE 2Z35ATHA/jOzF2pXwtGhUWSNdoYkKUvQaV0ljqwWEfzn3CNgO/hNZ6GHoMRgisloRgl3YtblGMdO WxKFMXcDzj2uZyVGB9freutryQAAAAAAAA== --=-v3l51HeEnSBUiCnj654T-- From nobody Mon Jul 15 08:50:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE91201F3; Mon, 15 Jul 2019 08:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 tqi5IDCw2VWU; Mon, 15 Jul 2019 08:50:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3E91201F2; Mon, 15 Jul 2019 08:50:03 -0700 (PDT) Received: from [172.17.0.10] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6FFnnau017756 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jul 2019 10:49:50 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563205792; bh=9q0uolW8/ciZiyn68JoGQq6UjhZr9+XfAL+wn3jQZJw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=W0EVExYt4LA+7HqFZAY130+/PEbDBm+RszwtUfbT5G0k1w/xKfl7sZttlYyoRSqL7 dSiHPG12WBfSgkLbfysxGf/bnyBD1J+CRkKy97HEyKw7doYOBHAdAOePOQfhvycI8I 3L1QtCCr7/lukVDgU0EGZZPlH54TBw96ffNds+XQ= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.0.10] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Mon, 15 Jul 2019 10:49:43 -0500 Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38C82875-AFA7-476B-A147-1433D10C2D20@nostrum.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> To: Eliot Lear Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 15:50:05 -0000 > On Jul 15, 2019, at 02:39, Eliot Lear wrote: >=20 > This give you the option for that not to be the case (people needn=E2=80=99= t worry about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric going= out of business anytime soon, for instance When I started IETF work, Nortel would have been on your list. /a=20= From nobody Mon Jul 15 08:52:19 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A24712011C; Mon, 15 Jul 2019 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 riUk9FDk5F_N; Mon, 15 Jul 2019 08:52:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC86120099; Mon, 15 Jul 2019 08:52:15 -0700 (PDT) Received: from [172.17.0.10] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6FFq7jH018194 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jul 2019 10:52:08 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563205928; bh=tz+Khkmdx6B6KSgNYSGIc+70Ydhya+LqbtvWk3lOPe8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gqN2/fn6Waxzhk/0Z2QfiCcVIT44uLNTeYb3KNdr0B2wEpoOlFXMuEK6NjgSg8KV0 9PCCLx6sYNJE8HxX0TZlMuT5MtK5W5C12sQRL8gcQmqB4GJ6oonxHZMGPczTJj/RlN zBYA3iTFKi2IlDBXmhppKGiFH/EexVi5cQOiIqTc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.0.10] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Mon, 15 Jul 2019 10:52:02 -0500 Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> To: Eliot Lear Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 15:52:17 -0000 > On Jul 15, 2019, at 02:39, Eliot Lear wrote: >=20 > To Adam=E2=80=99s broader point, there are at least several ways to approa= ch this. We can leave it to the vendor to decide which is correct, and we c= an continue to look to standardize ideas such as the one Michael had in the m= essage I=E2=80=99m replying to now. Yes; I think this is the important thing, and that specific mechanisms =E2=80= =94 if we believe they are useful to define =E2=80=94 could be worked on lat= er.=20 /a= From nobody Mon Jul 15 13:38:56 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2201E120115; Mon, 15 Jul 2019 13:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IXowKtMxYw-k; Mon, 15 Jul 2019 13:38:53 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F52120106; Mon, 15 Jul 2019 13:38:52 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id y8so8873291plr.12; Mon, 15 Jul 2019 13:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SJMiYIX2jZYgIv+NocPVpavHrfyN6sF55k+77dfR0AM=; b=H+uXACj1kmK8iyrK/JBqZnzmRPwxbsfcLd2NQYVmgsVmmwDf+PK14rcI4uMeLiHKbC /gpxe7VdOCfKXzp+v2YXHB1o6SpzpWhCFVaqAMPXLuvgw/cDFz3uiJ7orVg3HqJjLClN VqXeKATuNpeE+WF48DBtM/6xJXhOeIbn9xm0AtuB19m1CGt0VlAoswCRjCVwdZiTrA/B 2XOrGt9Crk3IPyO6+hWRe0s8YonXvx7EedWLJxraOe374mHMYieMyxgeCB7/wWmm9Eyo ryqcgycruMZeEdcriFIc5zctGVTHBIPDT09J5wksyBzc00gkC+IvrSw0lX2dy69utxMc wv+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SJMiYIX2jZYgIv+NocPVpavHrfyN6sF55k+77dfR0AM=; b=ltyLnj9TyDB4CFDT+gVX7HvYl4geu4ZHdZH8BryP3bzZw/ebZWhAK0Vhn+eqgyUYIK kyHgP5Z+RiALsWkgXHWChPOw9lXVwdA32rZLRp3dDCTCJv4Gf+1JjQPFaCyfFNp2+3QF GMbOuD1xmuzcB5dhNefX2wTzJAUvveau/o+KHVcvZUPCq3Y04ZgjvKnjV7EDv1gGcXkE FlaDGp6JzhzXJmH/N9zOHiSVYmplJzrUnlBRe/Uqs12jmwNI5ORWl65+lTuaSNmtYVYQ fBI/qkSql1gLg6tsmU37Sa5dTCWsoE//mlJmMvYgln5r4J7OX1BEfi5aqAAHwLEb2W8x XzGQ== X-Gm-Message-State: APjAAAXACpAPnt6zzYsT66lf9La8AsASkFR2FaaU8JiozE4sAlcnhWLJ FFN2hg7DPPcK/svFKt+czjc+6TW7 X-Google-Smtp-Source: APXvYqy8p/3MyIuLbP2zS/qIeBo4V4BujaYuXcoXsjLuO4A7usuZ17G/VJziLSVnw0Pvqdr4uIgMYw== X-Received: by 2002:a17:902:a514:: with SMTP id s20mr28932972plq.162.1563223132278; Mon, 15 Jul 2019 13:38:52 -0700 (PDT) Received: from [192.168.178.30] (40.226.69.111.dynamic.snap.net.nz. [111.69.226.40]) by smtp.gmail.com with ESMTPSA id s43sm21929748pjb.10.2019.07.15.13.38.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 13:38:51 -0700 (PDT) To: "Joel M. Halpern" , Michael Richardson , Eliot Lear Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> Date: Tue, 16 Jul 2019 08:38:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 20:38:55 -0000 On 15-Jul-19 16:45, Joel M. Halpern wrote: > I presume I am missing something basic. > I have tried to follow this discussion, as it seems to be about a > critical aspect of whether the BRSKI work is acceptable. > > I have assumed that what we needed is the ability for a buyer, who has > physical possession of the device, and possibly some simple (non > cryptographic) credentials provided by the seller to force the device to > reset what it thinks it is part of, and to emit in some accessible form > the information the buyer needs to be able to make this device part of > his network, using his authentication servers, etc. Yes, but *not* a solution that works if the device is stolen. That's why Eliot's comment: >> Many credentials are written on your wireless devices right now. doesn't provide an acceptable answer, IMHO. (As it doesn't for devices that are deployed where third parties might have physical access to them.) Brian > Have I got the wrong end of the stick? > Joel > > On 7/14/2019 5:33 PM, Michael Richardson wrote: >> >> Eliot Lear wrote: >> > Whether such a voucher would be pinned is something we do not have to >> > specify, with the risks of it not being pinned being born by the owner. >> >> I beg to differ! >> I think that the security properties are vastly different. >> It's why we decided when creating RFC8366 not to do bearer tokens. >> We simply didn't think we were competent enough to specify it tightly enough >> to not become a security disaster. >> >> An unpinned voucher is some kind of bearer token, and if disclosed has >> significant operational risk. As such, keeping it around/online is a serious >> issue. >> >> A voucher pinned to the public part of a keypair whose private key is >> kept offline (to be turned over to a new owner) is different because there >> are potentially far fewer things to keep private. Worse case, it's perhaps >> the same, I would agree. >> >> The bigger problem is that I don't see a way to define such an artifact in a >> timely fashion, nor do I know which WG we'd do it in. >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 15 14:11:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D78120132; Mon, 15 Jul 2019 14:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 ow53z_o39_cn; Mon, 15 Jul 2019 14:11:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2B01200D6; Mon, 15 Jul 2019 14:11:03 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6FLAhI2070157 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jul 2019 16:10:45 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563225047; bh=D0YBrEapElfK00XEMVxepsI1mPnevmHzrYR6HkAJKSY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=KmKIwH2chn2so9gJJH3RPXfzIQsyaoQqkRqe0Rpfwu49RoYFVyjQa2lae9vp7TepP QWaUwLpni+PR83WnxDHeme8M2ZH2WTGCYXBMJ2A29VA3lQpf26TxQ3/5u07yvPqVTI 12LxpmUJf9baxOMkS18SIHFdcbz+UAEUbmDWGrtM= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Brian E Carpenter , "Joel M. Halpern" , Michael Richardson , Eliot Lear Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> From: Adam Roach Message-ID: <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> Date: Mon, 15 Jul 2019 16:10:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 21:11:04 -0000 On 7/15/19 3:38 PM, Brian E Carpenter wrote: > On 15-Jul-19 16:45, Joel M. Halpern wrote: >> I presume I am missing something basic. >> I have tried to follow this discussion, as it seems to be about a >> critical aspect of whether the BRSKI work is acceptable. >> >> I have assumed that what we needed is the ability for a buyer, who has >> physical possession of the device, and possibly some simple (non >> cryptographic) credentials provided by the seller to force the device to >> reset what it thinks it is part of, and to emit in some accessible form >> the information the buyer needs to be able to make this device part of >> his network, using his authentication servers, etc. > Yes, but *not* a solution that works if the device is stolen. I'm actually a little ambivalent with respect to this use case. For the kind of devices that the document purports to be targeting, I would imagine that theft is in the range of parts-per-thousand (or lower) as compared to things like post-bankruptcy liquidation. If you can fix the first without ruining the second, great. /a From nobody Mon Jul 15 14:43:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662BD120194 for ; Mon, 15 Jul 2019 14:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 USazyEvUFW8H for ; Mon, 15 Jul 2019 14:42:54 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462C6120228 for ; Mon, 15 Jul 2019 14:42:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45ncTB1Swfz15Ky8; Mon, 15 Jul 2019 14:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563226974; bh=viEMeihZgTE4vNuYW6KVyyhXjTaQbc8kztpB+IZSVhU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mSK6MTmlsDc3YzCdmesWjVfT5xPobIrC0W4JcpmpP5tPVDfJSyEuzkFRlPCETHuq+ g+McuTMX5C3EGz0z1FSGb7zi0/l4DHWN2jk/biDs0S/RMVvyzB8/NdzFP7eudTJf3m ehrCzVjSjZKhBE0z4LTLWZNzTpyGJv9QTFElDZlM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45ncT93Rh8z15Kx3; Mon, 15 Jul 2019 14:42:53 -0700 (PDT) To: Eliot Lear Cc: anima@ietf.org, Adam Roach References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> From: "Joel M. Halpern" Message-ID: <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> Date: Mon, 15 Jul 2019 17:42:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 21:43:03 -0000 I would probably go a step further than Adam. Protecting the device so a thief can not use it in the thiefs' own network seems to me to be something that we should not be trying to achieve. An active non-goal. It is not our problem. And trying to achieve it has the implications that lead to this whole discussion about the original manufacturer controlling who can resell / re-buy the device. While manufacturers may like that, it does not seem to be something we should get involved in. At all. Yours, Joel On 7/15/2019 5:10 PM, Adam Roach wrote: > On 7/15/19 3:38 PM, Brian E Carpenter wrote: >> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>> I presume I am missing something basic. >>> I have tried to follow this discussion, as it seems to be about a >>> critical aspect of whether the BRSKI work is acceptable. >>> >>> I have assumed that what we needed is the ability for a buyer, who has >>> physical possession of the device, and possibly some simple (non >>> cryptographic) credentials provided by the seller to force the device to >>> reset what it thinks it is part of, and to emit in some accessible form >>> the information the buyer needs to be able to make this device part of >>> his network, using his authentication servers, etc. >> Yes, but *not* a solution that works if the device is stolen. > > > I'm actually a little ambivalent with respect to this use case. For the > kind of devices that the document purports to be targeting, I would > imagine that theft is in the range of parts-per-thousand (or lower) as > compared to things like post-bankruptcy liquidation. If you can fix the > first without ruining the second, great. > > /a > From nobody Mon Jul 15 15:28:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4C8120091 for ; Mon, 15 Jul 2019 15:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MSeVFz3ezU7T for ; Mon, 15 Jul 2019 15:28:18 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A8812002E for ; Mon, 15 Jul 2019 15:28:18 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id m4so8396407pgk.0 for ; Mon, 15 Jul 2019 15:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kW3P7PSJcwbT0Ad4yPoSeKNq/U8Dyg1jfmnsu6iupwU=; b=vD2kcNRf2L5DwvhY/d1GKrG9hTxRN7W0P+xyjyl6HmRWMhx6p2DgcaRNafORIpgyr5 Z5J1tq3MMJNpXB9R8f28AAmuF1WDC5bAgw+YaShvLe6Sk3qRBsaG+4EG5FiAz44yAqAU +yIkfazN+7muwh4Df8pt3RuZ1qz9e34Wq6fwycA0nPm76qR/tccXS4SNoWSRQ85h5dhL yueuWZuBEgvAPF3E9+5bIavEt1hR1v0JTOk9xiw3Y90e+ZN5RH6k51ENZ57BRG6IGBUL 0+rr00bIiod1CjUx0LBuFJwp9JOZlOJZ+h6CaVBlS42maI5+7Hm9UI/rr5/y7mDON0Uf GTFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kW3P7PSJcwbT0Ad4yPoSeKNq/U8Dyg1jfmnsu6iupwU=; b=avzcJoPta3ILqW16j+0vgcvkHg9c58akelVREy3CW5C42J8Rpa64HRuIAZpwEqVzTl vHIemMW1zkFTEEo6v9oMruLl5Qq0moUDNVbilavmbjmIKbU6cjIkUdFqDkVfKj5NbZx3 33TQA8cWIHTpay+J8+V2JTgeBiZd7vyNCtQrW9CWobsHKk878TUFk9uDYsm5YEjRw2f9 Mgf5ErxJEbEntk303bSrY9L0tLMoKzAZ/upkKlSzf6uScGaRa0XVohS80pfzrP9qzElq Bbsuojwzz2owIKCDjLMUYcXjlmqEWn/UTWdLbbkQ80T/py0oJ4/gjV8O5EUiAkgjjIEn WIcQ== X-Gm-Message-State: APjAAAXjs/hv6L+YwxBpwuwHwdx0ebpQBUlCJBrDqfaAP3j6rENFWZ0m zICfrCkhp/AE1nLu+9VT/PO/ngim X-Google-Smtp-Source: APXvYqylIuVZ9SGEJo6zr+mvxho0ca3+mPSMZxIEuZXijcGnsZ/rzb66STBwMw3bUvuEfYlLuubOpQ== X-Received: by 2002:a65:4045:: with SMTP id h5mr30209631pgp.247.1563229697881; Mon, 15 Jul 2019 15:28:17 -0700 (PDT) Received: from [192.168.178.30] (40.226.69.111.dynamic.snap.net.nz. [111.69.226.40]) by smtp.gmail.com with ESMTPSA id l15sm18428224pgf.5.2019.07.15.15.28.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 15:28:17 -0700 (PDT) To: "Joel M. Halpern" , Eliot Lear Cc: Adam Roach , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Tue, 16 Jul 2019 10:28:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 22:28:21 -0000 Joel, I'd be happy with that as long as there is a scope statement that makes it clear to the reader. Regards Brian On 16-Jul-19 09:42, Joel M. Halpern wrote: > I would probably go a step further than Adam. Protecting the device so > a thief can not use it in the thiefs' own network seems to me to be > something that we should not be trying to achieve. An active non-goal. > It is not our problem. And trying to achieve it has the implications > that lead to this whole discussion about the original manufacturer > controlling who can resell / re-buy the device. While manufacturers may > like that, it does not seem to be something we should get involved in. > At all. > > Yours, > Joel > > On 7/15/2019 5:10 PM, Adam Roach wrote: >> On 7/15/19 3:38 PM, Brian E Carpenter wrote: >>> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>>> I presume I am missing something basic. >>>> I have tried to follow this discussion, as it seems to be about a >>>> critical aspect of whether the BRSKI work is acceptable. >>>> >>>> I have assumed that what we needed is the ability for a buyer, who has >>>> physical possession of the device, and possibly some simple (non >>>> cryptographic) credentials provided by the seller to force the device to >>>> reset what it thinks it is part of, and to emit in some accessible form >>>> the information the buyer needs to be able to make this device part of >>>> his network, using his authentication servers, etc. >>> Yes, but *not* a solution that works if the device is stolen. >> >> >> I'm actually a little ambivalent with respect to this use case. For the >> kind of devices that the document purports to be targeting, I would >> imagine that theft is in the range of parts-per-thousand (or lower) as >> compared to things like post-bankruptcy liquidation. If you can fix the >> first without ruining the second, great. >> >> /a >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 15 17:03:18 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB5120147 for ; Mon, 15 Jul 2019 17:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 nKLW_gCJnh9o for ; Mon, 15 Jul 2019 17:03:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033D612004A for ; Mon, 15 Jul 2019 17:03:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45ngb56jZtz15L3n; Mon, 15 Jul 2019 17:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563235393; bh=PUAAQQLIBzbAgcOm+9sY2nlVQHwOuTvJwZk557bLT74=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FYFKgnkgKYcEcZCL6HCRX29XdRCXqVcjtDzJtQ/NSEcPSUHZU1oYTK0vBswiNEAO6 KbmyDYvODcqWymxessCK23G3zp585gWMPzwPGc8AqT/hdMepEmWGkL/h8J7ny5+IQ+ s5wvmQe1uoiELBTNx/Vh80taAWRKQGo6n/4ioVeY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45ngb46nklz15L23; Mon, 15 Jul 2019 17:03:12 -0700 (PDT) To: Brian E Carpenter Cc: Adam Roach , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <4a919e79-7b91-bf8a-38cb-3b3a02b8a730@joelhalpern.com> Date: Mon, 15 Jul 2019 20:03:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 00:03:16 -0000 Adding such scope text, along with the mechanism to get the needed credentials, would be fine with me. Joel On 7/15/2019 6:28 PM, Brian E Carpenter wrote: > Joel, > > I'd be happy with that as long as there is a scope statement that makes > it clear to the reader. > > Regards > Brian > > On 16-Jul-19 09:42, Joel M. Halpern wrote: >> I would probably go a step further than Adam. Protecting the device so >> a thief can not use it in the thiefs' own network seems to me to be >> something that we should not be trying to achieve. An active non-goal. >> It is not our problem. And trying to achieve it has the implications >> that lead to this whole discussion about the original manufacturer >> controlling who can resell / re-buy the device. While manufacturers may >> like that, it does not seem to be something we should get involved in. >> At all. >> >> Yours, >> Joel >> >> On 7/15/2019 5:10 PM, Adam Roach wrote: >>> On 7/15/19 3:38 PM, Brian E Carpenter wrote: >>>> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>>>> I presume I am missing something basic. >>>>> I have tried to follow this discussion, as it seems to be about a >>>>> critical aspect of whether the BRSKI work is acceptable. >>>>> >>>>> I have assumed that what we needed is the ability for a buyer, who has >>>>> physical possession of the device, and possibly some simple (non >>>>> cryptographic) credentials provided by the seller to force the device to >>>>> reset what it thinks it is part of, and to emit in some accessible form >>>>> the information the buyer needs to be able to make this device part of >>>>> his network, using his authentication servers, etc. >>>> Yes, but *not* a solution that works if the device is stolen. >>> >>> >>> I'm actually a little ambivalent with respect to this use case. For the >>> kind of devices that the document purports to be targeting, I would >>> imagine that theft is in the range of parts-per-thousand (or lower) as >>> compared to things like post-bankruptcy liquidation. If you can fix the >>> first without ruining the second, great. >>> >>> /a >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> From nobody Tue Jul 16 02:30:55 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9B11201B0; Tue, 16 Jul 2019 02:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kukEalKngngF; Tue, 16 Jul 2019 02:30:42 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EAA120183; Tue, 16 Jul 2019 02:30:42 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5812FD09F55EFED0220B; Tue, 16 Jul 2019 10:30:40 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 16 Jul 2019 10:30:39 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.238]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 17:30:34 +0800 From: Sheng Jiang To: Toerless Eckert , Alissa Cooper , "ibagdona@gmail.com" CC: Brian E Carpenter , IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: Reminder//RE: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) Thread-Index: AdU7uJ6QrQwWTRlFTTOtrjlX+9VBSw== Date: Tue, 16 Jul 2019 09:30:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299A0DDCE@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Reminder//RE: Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 09:30:45 -0000 Dear Alissa, Could you check whether the latest 2.0.9 version on WiKi addresses your blo= ck. If not, we would like to further modify it according to your new feedba= ck. We really would like to see progress on rechartering. Many thanks. https://trac.ietf.org/trac/anima/wiki/Recharter2019 Dear Ignas, could you upload the 2.0.9 version to datatracker? Many thanks, Sheng > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: Wednesday, July 10, 2019 7:34 PM > To: Alissa Cooper ; ibagdona@gmail.com > Cc: Sheng Jiang ; Brian E Carpenter > ; IESG ; anima-chairs@ietf.or= g; > anima@ietf.org > Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (= with > BLOCK and COMMENT) >=20 > Thanks for the update, Sheng! > Ignas: can you pls. upload wiki 2.0.9 charter to datatracker ? >=20 > Alissa: Thanks for your comments. I hope that the latest 2.0.9 version on= the wiki > as proposed by Sheng resolves your block. If not, then it would be great = if we > could accelerate resolving them so that we could actually start working o= n charter > 2 @ IETF105. >=20 > I think we always intended for what you proposed to be true, e.g: that wh= ats not > listed in the target work areas would require AD approval to be chartered= . I guess > we never wrote that explicitly because we had some even more specific > mentioning of explicit AD approval cases in earlier versions of the propo= sed > charter and those sentence got argued away by reviewers as being too > procedural and unnecessary for a charter. >=20 > Cheers > Toerless >=20 > On Mon, Jul 08, 2019 at 09:23:01AM -0400, Alissa Cooper wrote: > > Hi Sheng, > > > > > On Jul 3, 2019, at 10:39 AM, Sheng Jiang wrot= e: > > > > > > Hi, Alissa, > > > > > > Thanks for your kindly response. I have made a new version (2.0.8) ac= cording > to your feedback. Explanation in lines below. > > > > > > Please see https://trac.ietf.org/trac/anima/wiki/Recharter2019 > > > > > >> -----Original Message----- > > >> From: Alissa Cooper [mailto:alissa@cooperw.in] > > >> Sent: Wednesday, July 3, 2019 5:13 AM > > >> To: Brian E Carpenter > > >> Cc: IESG ; anima-chairs@ietf.org; anima@ietf.org > > >> Subject: Re: [Anima] Alissa Cooper's Block on > > >> charter-ietf-anima-01-05: (with BLOCK and COMMENT) > > >> > > >> Hi all, > > >> > > >> I???ve been discussing this on my weekly call with the OPS ADs for > > >> the last couple of weeks and based on the call that we had earlier > > >> today my understanding is that now would be a good time to re-review= . > > >> > > >> Regarding this text: "New work items will be adopted by the WG only > > >> if their contributors target them to enter WG last call within a > > >> number of IETF meeting cycles agreed by the AD.??? > > >> > > >> I still don???t get this. It is a very common case that > > >> contributors think their drafts are going to get through to WGLC in > > >> X cycles, and then they end up taking 2X or 10X because some new > > >> person wanders into the WG or some other work starts up in another > > >> WG that has an intersection with the work or someone changes jobs > > >> or any manner of other things. The WG needs milestones with dates, > preferably at the point of approving the re-charter. > > >> Those might be missed too, but there might as well not be two sets > > >> of markers laid down that are potentially going to be missed rather = than one > set. > > > > > > I have just deleted the sentence. It's something the chairs can do du= ring the > WG management process. We tried to give draft owners some pressure not to > be too slow by adding these text. I do agree this should not be so rigid = as these > text. So, let's take it out and the chairs will monitor the progress of W= G drafts > closely. > > > > Thanks. > > > > > > > >> Regarding the ???indicative scope of possible work items??? ??? > > >> this doesn???t address my concern about the WG???s scope. This > > >> charter is in contrast to the current ANIMA charter, which says: > > >> "The initial set of work items is limited to the above list to stay > > >> focused and avoid 'boiling the ocean???.??? I don???t see the > > >> rationale for not carrying that forward to the next set of specific > > >> work items where WG participants have demonstrated interest and > > >> intent to carry the work forward. If that is the list of initial mil= estone topics > listed, then limiting to that makes sense to me. > > > > > > I have added a specific list of work items into the initial milestone= list. > > > > > > Obviously, this initial milestone list does NOT cover all the topics > > > that WG participants have showed interests and willingness to work > > > on. The purpose to have this description of "indicative scope of > > > possible work items??? are actually two: A, limit the potential work > > > items not to be too wide > > > > I think my disconnect here is that the list doesn???t actually limit th= e WG???s > scope because it uses the language ???indicative scope of possible work i= tems??? > and ???including but not limited to.??? The five areas of work in this li= st seem > broad and large enough to keep the WG busy for quite some time. For the > charter to effectively limit the scope I think it would need to say ???Th= e scope of > work items is limited to:??? or something like that. > > > > Thanks, > > Alissa > > > > > , otherwise, people may take anything has the work "automatic" to the= WG; B, > to give the chairs a little bit flexibility to adopt new works beyond the= initial > milestone list. We try to avoid the problem that every time a new draft c= omes up, > it may become a charter revision, particularly, giving the current re-cha= rting > process have taken us many months. > > > > > > Best regards, > > > > > > Sheng > > > > > >> Thanks, > > >> Alissa > > >> > > >>> On Jun 10, 2019, at 9:02 PM, Brian E Carpenter > > >> wrote: > > >>> > > >>> Hi all, > > >>> > > >>> I've taken the liberty of posting an update to the draft charter > > >>> at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried to > > >>> respond to all the IESG comments, and in particular: > > >>> > > >>> (a) I deleted Intent from the summarised reference model > > >>> framework, since the reference model doesn't usefully define Intent= . > > >>> > > >>> (b) I tried to make the statement about workload throttling more > > >>> implementable. > > >>> > > >>> (c) I still think that the laundry list of *possible* work items > > >>> is useful (it helps to define the scope) but I've tried make it > > >>> clear that it is only the "indicative scope of possible work items"= . > > >>> It really isn't mission creep; all the items mentioned relate > > >>> directly to the ANI and AF topics. > > >>> > > >>> (d) I intentionally removed the reference to not covering machine > > >>> learning and AI. It isn't suggested anywhere in the reference > > >>> model, so why even mention it? > > >>> > > >>> (e) I fixed nits and tuned the wording in several places. > > >>> > > >>> I hope this helps. We really need a new charter before Montreal. > > >>> WG Chairs and AD, over to you... > > >>> > > >>> Regards > > >>> Brian Carpenter > > >>> > > >>> On 02-May-19 08:39, Brian E Carpenter wrote: > > >>>> Hi Alissa, > > >>>> > > >>>> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: > > >>>> ... > > >>>>> ---------------------------------------------------------------- > > >>>>> ---- > > >>>>> -- > > >>>>> BLOCK: > > >>>>> ---------------------------------------------------------------- > > >>>>> ---- > > >>>>> -- > > >>>>> > > >>>>> (1) "Acceptance of work items by the WG will be > > >>>>> scheduled/throttled so that contributors can target them to > > >>>>> enter WG last call after not more than a number of IETF meeting c= ycles > agreed by the AD." > > >>>>> > > >>>>> I don't understand the implications of this. What happens if the > > >>>>> adopted work items have not entered WGLC after the agreed number > > >>>>> of cycles? If the answer is anything other than "the WG abandons > > >>>>> the work," I don't understand how this is a throttling > > >>>>> mechanism. A throttling mechanism would need an explicit limit > > >>>>> on the number of > > >> adopted work items at any one time, I think. > > >>>> > > >>>> I agree that the text is a bit illogical. In a sense it's > > >>>> unnecessary, because every WG should be matching its workload to > > >>>> its capacity. Maybe that's all we should say, rather than trying > > >>>> to describe a > > >> slightly vague algorithm? > > >>>> > > >>>>> (2) The proposed work items is a very large and somewhat > > >>>>> unbounded list of items, whereas the purpose of writing a > > >>>>> charter is to scope the work of the WG and hopefully set out a > > >>>>> realistic work plan that will be accompanied by deployment. For > > >>>>> a WG that has produced 5 documents in the last 5 years, I think > > >>>>> the charter needs to more narrowly focus on the most highly > > >>>>> prioritized work items. Once those are nearing completion, it > > >>>>> seems as though evaluation of what is needed next based on > > >>>>> deployment experience would then dictate the next > > >> set of items for another re-charter. > > >>>> > > >>>> I think the point here is that now that the relatively small > > >>>> number of infrastructure documents are almost finished, the next > > >>>> stage opens up the possibilities for a much wider range of work > > >>>> that builds on the infrastructure. The priorities aren't even > > >>>> obvious. So this goes with the previous point, and to quite some > > >>>> extent the criteria will be whether the WG has capacity more than = which > topic has priority. > > >>>> > > >>>> That's why there's a bucket list of work items and a short list > > >>>> of immediate milestones. > > >>>> > > >>>> Would this help? > > >>>> > > >>>> s/Proposed work items include.../Possible work items include.../ > > >>>> > > >>>>> > > >>>>> > > >>>>> ---------------------------------------------------------------- > > >>>>> ---- > > >>>>> -- > > >>>>> COMMENT: > > >>>>> ---------------------------------------------------------------- > > >>>>> ---- > > >>>>> -- > > >>>>> > > >>>>> It would be good to see milestones with dates before this gets > approved. > > >>>>> > > >>>>> I think this charter would benefit from an English edit pass > > >>>>> before going > > >> out for external review. > > >>>> > > >>>> I'll volunteer, when the open issues have been resolved. > > >>>> > > >>>>> What is "compounding environment"? > > >>>> > > >>>> An excellent question. > > >>>> > > >>>> Brian > > >>>> > > > >=20 > -- > --- > tte@cs.fau.de From nobody Tue Jul 16 03:16:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9035C120229; Tue, 16 Jul 2019 03:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 HKxqfrMbbUHB; Tue, 16 Jul 2019 03:16:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EF51200B2; Tue, 16 Jul 2019 03:16:03 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A23E15A09EBD12D61611; Tue, 16 Jul 2019 11:16:01 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 16 Jul 2019 11:16:01 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.238]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 18:15:53 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: List of received time-slot requests for the ANIMA meetings Thread-Index: AdU7v2ySGIUVYV6eSkOPwbWzm2o0OQ== Date: Tue, 16 Jul 2019 10:15:52 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299A0E816@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299A0E816NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] List of received time-slot requests for the ANIMA meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 10:16:06 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299A0E816NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The below is the list that the chairs received time-slot requests for the A= NIMA meetings in the coming IETF 105 next week. Could you check any items m= issed? If yes, please contact the chairs by this Wednesday. Afterwards, cha= irs would arrange the agenda accordingly. Thanks and regards, Sheng Session 1: Update for ANIMA WG rechartering progress Update for draft-ietf-anima-autonomic-control-plane-19 draft-ietf-anima-grasp-api (GRASP API) Speaker: Brian Carpenter (on site) Purpose: Reminder of draft and request for WG Last Call Time: 5 minutes Name of time slot: Information Distribution in Autonomic Networking Name of draft(s): Information Distribution in Autonomic Networking Time requested: 10 mins Presenter name(s): Bing Liu draft-carpenter-anima-asa-guidelines and draft-carpenter-anima-grasp-bulk (= Drafts related to autonomic ecosystem) Speaker: Brian Carpenter (on site) Purpose: Reminder of drafts and requests for WG adoption (under new charter= ) Time: 10 minutes draft-carpenter-anima-l2acp-scenarios (Layer 2 ACP) Speaker: Brian Carpenter (on site) Purpose: Introducing a new proposal (deferred from IETF104) Time: 15 minutes Name of time slot: Autonomic setup of fog monitoring agents Name of draft(s): draft-bernardos-anima-fog-monitoring-00 Time requested: 5-10 min Presenter name(s): Carlos J. Bernardos Session 2 Update for draft-ietf-anima-bootstrapping-keyinfra-22 Update for draft-ietf-anima-constrained-voucher-05 Name of time slot: BRSKI-AE (BRSKI with support for asynchronous enrollment= ) Name of draft(s): draft-fries-anima-brski-async-enroll-01.txt Time requested: 10min Presenter name(s): Eliot Lear Name of time slot: Constrained join proxy for contstrained BRSKI Name of draft(s): draft-vanderstok-anima-constrained-join-proxy Time requested: 15 mins Presenter name(s): Peter van der Stok Name of time slot: BRSKI / Afternoon session I Name of draft(s): draft-friel-acme-integrations Time requested: 10 mins Presenter name(s): Owen Friel --_000_5D36713D8A4E7348A7E10DF7437A4B9299A0E816NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

The below is the list that the = chairs received time-slot requests for the ANIMA meetings in the coming IET= F 105 next week. Could you check any items missed? If yes, please contact t= he chairs by this Wednesday. Afterwards, chairs would arrange the agenda accordingly.

 

Thanks and regards,<= /span>

 

Sheng

 

Session 1:

 

Update for ANIMA WG recharterin= g progress

 

Update for draft-ietf-anima-aut= onomic-control-plane-19

 

draft-ietf-anima-grasp-api (GRA= SP API)

Speaker: Brian Carpenter (on si= te)

Purpose: Reminder of draft and = request for WG Last Call

Time: 5 minutes

 

Name of time slot: Information = Distribution in Autonomic Networking

Name of draft(s): Information D= istribution in Autonomic Networking

Time requested: 10 mins

Presenter name(s): Bing Liu

 

draft-carpenter-anima-asa-guide= lines and draft-carpenter-anima-grasp-bulk (Drafts related to autonomic eco= system)

Speaker: Brian Carpenter (on si= te)

Purpose: Reminder of drafts and= requests for WG adoption (under new charter)

Time: 10 minutes

 

draft-carpenter-anima-l2acp-sce= narios (Layer 2 ACP)

Speaker: Brian Carpenter (on si= te)

Purpose: Introducing a new prop= osal (deferred from IETF104)

Time: 15 minutes

 

Name of time slot: Autonomic se= tup of fog monitoring agents

Name of draft(s): draft-bernard= os-anima-fog-monitoring-00

Time requested: 5-10 min

Presenter name(s): Carlos J. Be= rnardos

 

 

Session 2

 

Update for draft-ietf-anima-boo= tstrapping-keyinfra-22

 

Update for draft-ietf-anima-con= strained-voucher-05

 

Name of time slot: BRSKI-AE (BR= SKI with support for asynchronous enrollment)

Name of draft(s): draft-fries-a= nima-brski-async-enroll-01.txt

Time requested: 10min

Presenter name(s): Eliot Lear

 

Name of time slot: Constrained = join proxy for contstrained BRSKI

Name of draft(s): draft-vanders= tok-anima-constrained-join-proxy

Time requested: 15 mins

Presenter name(s): Peter van de= r Stok

 

Name of time slot: BRSKI / Afte= rnoon session I

Name of draft(s): draft-friel-a= cme-integrations

Time requested: 10 mins

Presenter name(s): Owen Friel

--_000_5D36713D8A4E7348A7E10DF7437A4B9299A0E816NKGEML515MBSchi_-- From nobody Tue Jul 16 04:21:49 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550B91203FB for ; Tue, 16 Jul 2019 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 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 HITUz5CFSImj for ; Tue, 16 Jul 2019 04:21:44 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA5912004D for ; Tue, 16 Jul 2019 04:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10177; q=dns/txt; s=iport; t=1563276104; x=1564485704; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=u05th4kIhG68DbjIOSWYq785lEu1t35N1vXwu4hB7LY=; b=XCcf0B55E85A3uz16QpK1SAXA1GS2rIwTpWhj4DsAw7xXd33yf6gQRhF T66lR7OQ1UfomhIPNr4st3ws1OCy1Wz3UW5UoxvrA+pfDErqy+7bOnSLs obvX6i3aiG5R2LeIC2bKCiRMR9kUuoo4RpeN3iYCacYfw3mAXNiUJQ08a E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAAB2si1d/xbLJq1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBZ4NSATIohByIe4tUJZJ6hheBZwIHAQEBCQMBAS8BAYRAAoMUOBM?= =?us-ascii?q?BAwEBBAEBAgEFbYVIhUoBAQEBAgEjVgULCxgjBwICVwYKCRsEgwMBgXsPrFq?= =?us-ascii?q?BMoVHhGsQgTSBUYolgX+BEScME4FOfj6ELYMhMoImBIw4iDmVcgmCG4IfgQy?= =?us-ascii?q?QYRuNN4pTi1uWH4MLAgQGBQIVgWchgVgzGggbFWUBgkE+gjqODz0DMJBFAQE?= X-IronPort-AV: E=Sophos;i="5.63,498,1557187200"; d="asc'?scan'208,217";a="14298455" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2019 11:21:41 +0000 Received: from [10.61.214.237] ([10.61.214.237]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6GBLeHb009153 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Jul 2019 11:21:41 GMT From: Eliot Lear Message-Id: <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_13DD1178-3C12-4B95-B146-244F1864F9D3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 13:21:38 +0200 In-Reply-To: <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> Cc: anima@ietf.org, Adam Roach To: "Joel M. Halpern" References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.237, [10.61.214.237] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 11:21:46 -0000 --Apple-Mail=_13DD1178-3C12-4B95-B146-244F1864F9D3 Content-Type: multipart/alternative; boundary="Apple-Mail=_A42750EF-C053-4CAC-B350-62E77E0455BD" --Apple-Mail=_A42750EF-C053-4CAC-B350-62E77E0455BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joel, > On 15 Jul 2019, at 23:42, Joel M. Halpern wrote: >=20 > I would probably go a step further than Adam. Protecting the device = so a thief can not use it in the thiefs' own network seems to me to be = something that we should not be trying to achieve. An active non-goal. = It is not our problem. > And trying to achieve it has the implications that lead to this whole = discussion about the original manufacturer controlling who can resell / = re-buy the device. I would rather we redressed this directly. There is an entire work flow = that involves zero-touch provisioning that at least two, and likely four = large platforms are driving toward, that all require some sort of = manufacturer assertion for device ownership to be transferred. This is = not just a good idea or an anti-theft mechanism, but an aspect that is = required for zero-touch, particularly with wireless, where network = selection has to occur. While in that sense, you might say, = =E2=80=9CAnti-theft wasn=E2=80=99t the goal=E2=80=9D, it is certainly a = nice add-on, and it seems like a valuable function. Personally I like that we had this discussion. I think the BRSKI work = will be much improved because of it, and people have a better = understanding of how the mechanisms can be used/abused as a result. I = only wish we had had it earlier. So now let=E2=80=99s talk about anti-theft and counterfeiting. BRSKI = has an interesting link to both. If a manufacturer is able to show the = customer what devices have been registered, any device that seems to be = operational but is NOT registered has to be considered suspect by the = customer. That=E2=80=99s a nice counterfeit protection, and it isn=E2=80=99= t there by accident. Similarly having a way to say, =E2=80=9Cthe thing won=E2=80=99t join an = unauthorized network=E2=80=9D is a very strong theft deterrent, very = much akin to the electronic keys that we see now in cars. You generally = can no longer go to the local locksmith to get a duplicate key for a = great many cars, but your theft insurance has dropped through the floor = (particularly if you own a Honda). Might GM, Ford, BMW etc might fail? = Sure. No more new keys for those cars: the old ones had better suffice. In this case we discussed several approaches to deal with the case where = the supplier drops dead. IMHO that=E2=80=99s a good outcome. Eliot > While manufacturers may like that, it does not seem to be something = we should get involved in. At all. >=20 > Yours, > Joel >=20 > On 7/15/2019 5:10 PM, Adam Roach wrote: >> On 7/15/19 3:38 PM, Brian E Carpenter wrote: >>> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>>> I presume I am missing something basic. >>>> I have tried to follow this discussion, as it seems to be about a >>>> critical aspect of whether the BRSKI work is acceptable. >>>>=20 >>>> I have assumed that what we needed is the ability for a buyer, who = has >>>> physical possession of the device, and possibly some simple (non >>>> cryptographic) credentials provided by the seller to force the = device to >>>> reset what it thinks it is part of, and to emit in some accessible = form >>>> the information the buyer needs to be able to make this device part = of >>>> his network, using his authentication servers, etc. >>> Yes, but *not* a solution that works if the device is stolen. >> I'm actually a little ambivalent with respect to this use case. For = the kind of devices that the document purports to be targeting, I would = imagine that theft is in the range of parts-per-thousand (or lower) as = compared to things like post-bankruptcy liquidation. If you can fix the = first without ruining the second, great. >> /a --Apple-Mail=_A42750EF-C053-4CAC-B350-62E77E0455BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Joel,

On 15 Jul 2019, at 23:42, Joel M. Halpern = <jmh@joelhalpern.com> wrote:

I = would probably go a step further than Adam.  Protecting the device = so a thief can not use it in the thiefs' own network seems to me to be = something that we should not be trying to achieve.  An active = non-goal. It is not our problem.

 And trying to achieve it has the implications that = lead to this whole discussion about the original manufacturer = controlling who can resell / re-buy the = device.

I would = rather we redressed this directly.  There is an entire work flow = that involves zero-touch provisioning that at least two, and likely four = large platforms are driving toward, that all require some sort of manufacturer assertion for = device ownership to be transferred.  This is not just a good idea = or an anti-theft mechanism, but an aspect that is required for = zero-touch, particularly with wireless, where network selection has to = occur.  While in that sense, you might say, =E2=80=9CAnti-theft = wasn=E2=80=99t the goal=E2=80=9D, it is certainly a nice add-on, and it = seems like a valuable function.

Personally I like that we = had this discussion.  I think the BRSKI work will be much improved = because of it, and people have a better understanding of how the = mechanisms can be used/abused as a result.  I only wish we had had = it earlier.

So now let=E2=80=99s = talk about anti-theft and counterfeiting.  BRSKI has an interesting = link to both.  If a manufacturer is able to show the customer what = devices have been registered, any device that seems to be operational = but is NOT registered has to be considered suspect by the customer. =  That=E2=80=99s a nice counterfeit protection, and it isn=E2=80=99t = there by accident.

Similarly having = a way to say, =E2=80=9Cthe thing won=E2=80=99t join an unauthorized = network=E2=80=9D is a very strong theft deterrent, very much akin to the = electronic keys that we see now in cars.  You generally can no = longer go to the local locksmith to get a duplicate key for a great many = cars, but your theft insurance has dropped through the floor = (particularly if you own a Honda).  Might GM, Ford, BMW etc might = fail?  Sure.  No more new keys for those cars: the old ones = had better suffice.

In this case we = discussed several approaches to deal with the case where the supplier = drops dead.  IMHO that=E2=80=99s a good outcome.

Eliot




 While = manufacturers may like that, it does not seem to be something we should = get involved in. At all.

Yours,
Joel

On 7/15/2019 5:10 PM, Adam = Roach wrote:
On = 7/15/19 3:38 PM, Brian E Carpenter wrote:
On 15-Jul-19 16:45, Joel M. Halpern wrote:
I presume I am missing = something basic.
I have tried to follow this discussion, = as it seems to be about a
critical aspect of whether the = BRSKI work is acceptable.

I have assumed = that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple = (non
cryptographic) credentials provided by the seller to = force the device to
reset what it thinks it is part of, = and to emit in some accessible form
the information the = buyer needs to be able to make this device part of
his = network, using his authentication servers, etc.
Yes, but *not* a solution that works if the = device is stolen.
I'm actually a little = ambivalent with respect to this use case. For the kind of devices that = the document purports to be targeting, I would imagine that theft is in = the range of parts-per-thousand (or lower) as compared to things like = post-bankruptcy liquidation. If you can fix the first without ruining = the second, great.
/a

= --Apple-Mail=_A42750EF-C053-4CAC-B350-62E77E0455BD-- --Apple-Mail=_13DD1178-3C12-4B95-B146-244F1864F9D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXS2zQgAKCRBugA9nE248 uK8nAKDzxgarMDa5IBPHQEP236AVWzWNuwCg26JY+05i0MN3uylyoAXZeBax1HI= =B/Wy -----END PGP SIGNATURE----- --Apple-Mail=_13DD1178-3C12-4B95-B146-244F1864F9D3-- From nobody Tue Jul 16 05:59:55 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9EE12004F for ; Tue, 16 Jul 2019 05:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Hw823jyg-O3o for ; Tue, 16 Jul 2019 05:59:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15469120411 for ; Tue, 16 Jul 2019 05:59:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45p0qB05c8zKnLP; Tue, 16 Jul 2019 05:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563281990; bh=jpTaBj3Jx3b3W/DObS1q+ebX6VdNCmnVPZQ5LaRSNTc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=El6uG0JRk8V+xMhljTeD6scRaqeVEVlTGsjBycf4hOogR7nfFlMSAUrWB0lClmtMe A5HlmUNGm0ZxXjdwg/bpEktESQ5SO5zgH25V4zgSxD6gt1IUU2ABUmQ1U6l0yt3Q8B TW0OAisPu6xcSxbJcYKcMcUfoRLLcr7uvYBVOBO8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45p0q82Z80z14L3M; Tue, 16 Jul 2019 05:59:48 -0700 (PDT) To: Eliot Lear Cc: anima@ietf.org, Adam Roach References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> From: Joel Halpern Direct Message-ID: Date: Tue, 16 Jul 2019 08:59:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 12:59:53 -0000 I am having trouble connecting your reply with my request. Let's take the direct issue first, and then the analogy. I had suggested a specific enhancement to device behavior. The response was "but that removes the theft protection." It is that form of theft protection that I am objecting to. As far as I can tell, the mechanism I suggested does not break zero touch. It allows someone who controls their network, and who physically controls a new device, to put that new device in their network without asking anyone's permission. It does not permit someone with a device, but not network control, from adding that device to the network. It does not permit someone with control of the network, but not physical access to the device, to achieve anything special. So it seems compatible with the goals. In terms of the analogy, I would have problem with IEtF defining a new protocol that added significant risk to the buyer when they buy from new vendors. And existing vendors do go out of businesses. And vendors do end-of-life products. (You can't get a new key to your car because the vendor has stopped supporting that model???) Now it may be that the particular approach I suggested won't work. But it seems to me that there needs to be a way for folks to keep using, and to keep re-selling, devices without the support of the vendor. That usage may not get all the zero-touch advantages that supported re-sale would get. But it has to work. And putting the onus for that on the original vendor does NOT seem an effective solution. Yours, Joel On 7/16/2019 7:21 AM, Eliot Lear wrote: > Hi Joel, > >> On 15 Jul 2019, at 23:42, Joel M. Halpern > > wrote: >> >> I would probably go a step further than Adam.  Protecting the device >> so a thief can not use it in the thiefs' own network seems to me to be >> something that we should not be trying to achieve.  An active >> non-goal. It is not our problem. > >>  And trying to achieve it has the implications that lead to this whole >> discussion about the original manufacturer controlling who can resell >> / re-buy the device. > > I would rather we redressed this directly.  There is an entire work flow > that involves zero-touch provisioning that at least two, and likely four > large platforms are driving toward, that *all* require some sort of > manufacturer assertion for device ownership to be transferred.  This is > not just a good idea or an anti-theft mechanism, but an aspect that is > required for zero-touch, particularly with wireless, where network > selection has to occur.  While in that sense, you might say, “Anti-theft > wasn’t the goalâ€, it is certainly a nice add-on, and it seems like a > valuable function. > > Personally I *like* that we had this discussion.  I think the BRSKI work > will be much improved because of it, and people have a better > understanding of how the mechanisms can be used/abused as a result.  I > only wish we had had it earlier. > > So now let’s talk about anti-theft and counterfeiting.  BRSKI has an > interesting link to both.  If a manufacturer is able to show the > customer what devices have been registered, any device that seems to be > operational but is NOT registered has to be considered suspect by the > customer.  That’s a nice counterfeit protection, and it isn’t there by > accident. > > Similarly having a way to say, “the thing won’t join an unauthorized > network†is a very strong theft deterrent, very much akin to the > electronic keys that we see now in cars.  You generally can no longer go > to the local locksmith to get a duplicate key for a great many cars, but > your theft insurance has dropped through the floor (particularly if you > own a Honda).  Might GM, Ford, BMW etc might fail?  Sure.  No more new > keys for those cars: the old ones had better suffice. > > In this case we discussed several approaches to deal with the case where > the supplier drops dead.  IMHO that’s a good outcome. > > Eliot > > > > >>  While manufacturers may like that, it does not seem to be something >> we should get involved in. At all. >> >> Yours, >> Joel >> >> On 7/15/2019 5:10 PM, Adam Roach wrote: >>> On 7/15/19 3:38 PM, Brian E Carpenter wrote: >>>> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>>>> I presume I am missing something basic. >>>>> I have tried to follow this discussion, as it seems to be about a >>>>> critical aspect of whether the BRSKI work is acceptable. >>>>> >>>>> I have assumed that what we needed is the ability for a buyer, who has >>>>> physical possession of the device, and possibly some simple (non >>>>> cryptographic) credentials provided by the seller to force the >>>>> device to >>>>> reset what it thinks it is part of, and to emit in some accessible form >>>>> the information the buyer needs to be able to make this device part of >>>>> his network, using his authentication servers, etc. >>>> Yes, but *not* a solution that works if the device is stolen. >>> I'm actually a little ambivalent with respect to this use case. For >>> the kind of devices that the document purports to be targeting, I >>> would imagine that theft is in the range of parts-per-thousand (or >>> lower) as compared to things like post-bankruptcy liquidation. If you >>> can fix the first without ruining the second, great. >>> /a > From nobody Tue Jul 16 06:40:47 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938AB120604 for ; Tue, 16 Jul 2019 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 sMtbLQdPwfhy for ; Tue, 16 Jul 2019 06:40:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71603120602 for ; Tue, 16 Jul 2019 06:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3719; q=dns/txt; s=iport; t=1563284443; x=1564494043; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=BWxnhjM29RjHbhWcMlgE6hRzj4AcAIPmz2vdxprP4A0=; b=fTTZWeLi8h9eqdc+OQzsDeYqribdw5BHitKWgUwTKmPdMXTSvAz01izh MM2twJSOoTllxIBg+S2u2vYBzbgwkLE99FYBzpK5jtgX5TIN55hAilR49 GCs3jbX+4NcMMV0g2uhPe5+5ljWMrcX/vkpmX1z0Iar6LEJlVDjuzVxXe Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACR0y1d/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGDUQEgEiiEHIh7i1UlmH0UgWcCBwEBAQkDAQE?= =?us-ascii?q?vAQGEQAKCXTYHDgEDAQEEAQECAQVthTwMhUoBAQEBAgEjBFIFCwsYIwcCAlc?= =?us-ascii?q?GExkCgwcBgXsPrH5/M4VHhG8QgTQBgVCKJYF/gREnDBOCTD6ELQGDIDKCJgS?= =?us-ascii?q?MOAoSiB2VcgmCG4IfgQyQYRuCLYsKilOOZpMUgwsCBAYFAhWBVwIvRIEUMxo?= =?us-ascii?q?IGxVlAYJBPoI6hACKDz0DMJAzAQE?= X-IronPort-AV: E=Sophos;i="5.64,270,1559520000"; d="asc'?scan'208";a="14298098" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2019 13:40:27 +0000 Received: from [10.61.214.125] ([10.61.214.125]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6GDePh2012953 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Jul 2019 13:40:27 GMT From: Eliot Lear Message-Id: <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B422782D-095F-402B-A86C-6FBF23AE3133"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 15:40:27 +0200 In-Reply-To: Cc: anima@ietf.org, Adam Roach To: Joel Halpern Direct References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.125, [10.61.214.125] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 13:40:46 -0000 --Apple-Mail=_B422782D-095F-402B-A86C-6FBF23AE3133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joel, > On 16 Jul 2019, at 14:59, Joel Halpern Direct = wrote: >=20 > I am having trouble connecting your reply with my request. > Let's take the direct issue first, and then the analogy. >=20 > I had suggested a specific enhancement to device behavior. The = response was "but that removes the theft protection." It is that form = of theft protection that I am objecting to. As far as I can tell, the = mechanism I suggested does not break zero touch. It allows someone who = controls their network, and who physically controls a new device, to put = that new device in their network without asking anyone's permission. > It does not permit someone with a device, but not network control, = from adding that device to the network. It does not permit someone with = control of the network, but not physical access to the device, to = achieve anything special. So it seems compatible with the goals. My apologies I took your statement as something more general than you = intended. With respect to this from earlier: > I have assumed that what we needed is the ability for a buyer, who has = physical possession of the device, and possibly some simple (non = cryptographic) credentials provided by the seller to force the device to = reset what it thinks it is part of, and to emit in some accessible form = the information the buyer needs to be able to make this device part of = his network, using his authentication servers, etc. That was indeed what we discussed. We just got into means a bit more = than perhaps necessary. I=E2=80=99ll point out that it=E2=80=99s always = going to be a manufacturer call on how best to do this; and how to = transport credentials, and how to keep them safe, even. >=20 > In terms of the analogy, I would have problem with IEtF defining a new = protocol that added significant risk to the buyer when they buy from new = vendors. > And existing vendors do go out of businesses. And vendors do = end-of-life products. (You can't get a new key to your car because the = vendor has stopped supporting that model???) I wouldn=E2=80=99t implement a 1:1 mapping products->MASA server = function. That seems excessive. And rare is the case when a vendor = EOLs a product and then cripples it through an update mechanism. The = only issue here is whether a database entry would stay around. >=20 > Now it may be that the particular approach I suggested won't work. = But it seems to me that there needs to be a way for folks to keep using, = and to keep re-selling, devices without the support of the vendor. That = usage may not get all the zero-touch advantages that supported re-sale = would get. But it has to work. And putting the onus for that on the = original vendor does NOT seem an effective solution. I think you mean, =E2=80=9Crequiring the vendor to stay around for ever = doesn=E2=80=99t seem like an effective solution.=E2=80=9D Again, I = don=E2=80=99t want to overgeneralize. Eliot --Apple-Mail=_B422782D-095F-402B-A86C-6FBF23AE3133 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXS3TywAKCRBugA9nE248 uOf9AJ0enpSKB2MzB3k286enZRkLUFCHZACgj6dVbsWy4AGqgel7hk4n5clz4GA= =1rmw -----END PGP SIGNATURE----- --Apple-Mail=_B422782D-095F-402B-A86C-6FBF23AE3133-- From nobody Tue Jul 16 06:45:11 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C65120483; Tue, 16 Jul 2019 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Rqmx8uiS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rBfupn3J 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 pJaha100em1e; Tue, 16 Jul 2019 06:44:57 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3508120086; Tue, 16 Jul 2019 06:44:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1F4D221903; Tue, 16 Jul 2019 09:44:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 16 Jul 2019 09:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=n yeDGjfNd/volpbfKxe9L/jJaI9dHeHut+vo6WI6E1M=; b=Rqmx8uiS54709ygNO bdWga6nhxL7MnW5+kfmpSOiFo4rxjtNqvzt75gXLLP5NL1KR/0NNjfTVfSVxoDFz xpbo/8NIROEvnnsaE475VonOPh0zOclmp/8oYhHtfIYpqpsSR6HW5OPsxr73SJ6o CZ5IUSflEFY0RPQuhti5P+MA+1gNgKuLTbP0AO46Ht/xZrLF8BQ4mHhJOcgIsmWs VCyfv78TwMWKkhMXRVVxjyVp3WC0T4Ke1wOn5boX7qMZJ/HJL7F43oCdfTuZMi+C Kg5VZlZcxedfTcVobBB6cmJAAGsTzaL0UJXyZCSbOWZlO6OK1W3X4uZqxzc+fR7C 5LHdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=nyeDGjfNd/volpbfKxe9L/jJaI9dHeHut+vo6WI6E 1M=; b=rBfupn3JrB4XR8bhw3BCKkEABZB7kIoxD1DqEwTLaaOKMAlo/HLgVHgKG 0YW1P4E1pJcXeZjjD8ctMtw04ET3tmVVxrpYmXbEQfEekE1H0owyXkouKY7xCPaq 1U2fsR3upADNYU9LjurBwW4IeemVgSDegBcOUmpZET7xxed/KPqlV+cH6jZmXJYb 9JFmaa6TjJwgf1aXI2ddeQ24lXzd2YyAgtS/6YOOjg+FHpOOzskWZ6BZbilJQ++a LdAgFT7J4M0ZsV4UH44RS0kxJwmIzf9Ln7KJxgDW5xXGpDP6pZe8bfqfeBkIOKop LelPJfgyEUNxJUVQCYKvjff7vz5Sw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddriedtgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejfeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 2036D80060; Tue, 16 Jul 2019 09:44:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299A0DDCE@NKGEML515-MBS.china.huawei.com> Date: Tue, 16 Jul 2019 09:44:53 -0400 Cc: Toerless Eckert , "ibagdona@gmail.com" , Brian E Carpenter , IESG , "anima-chairs@ietf.org" , "anima@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <228BD1A3-4612-43F6-B26C-12DB736775F9@cooperw.in> References: <5D36713D8A4E7348A7E10DF7437A4B9299A0DDCE@NKGEML515-MBS.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Reminder//RE: Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 13:45:01 -0000 Thanks. I=E2=80=99ll clear my block when the 2.0.9 version gets uploaded = to the datatracker. Alissa > On Jul 16, 2019, at 5:30 AM, Sheng Jiang = wrote: >=20 > Dear Alissa, >=20 > Could you check whether the latest 2.0.9 version on WiKi addresses = your block. If not, we would like to further modify it according to your = new feedback. We really would like to see progress on rechartering. Many = thanks. >=20 > https://trac.ietf.org/trac/anima/wiki/Recharter2019 >=20 > Dear Ignas, could you upload the 2.0.9 version to datatracker? Many = thanks, >=20 > Sheng >=20 >> -----Original Message----- >> From: Toerless Eckert [mailto:tte@cs.fau.de] >> Sent: Wednesday, July 10, 2019 7:34 PM >> To: Alissa Cooper ; ibagdona@gmail.com >> Cc: Sheng Jiang ; Brian E Carpenter >> ; IESG ; = anima-chairs@ietf.org; >> anima@ietf.org >> Subject: Re: [Anima] Alissa Cooper's Block on = charter-ietf-anima-01-05: (with >> BLOCK and COMMENT) >>=20 >> Thanks for the update, Sheng! >> Ignas: can you pls. upload wiki 2.0.9 charter to datatracker ? >>=20 >> Alissa: Thanks for your comments. I hope that the latest 2.0.9 = version on the wiki >> as proposed by Sheng resolves your block. If not, then it would be = great if we >> could accelerate resolving them so that we could actually start = working on charter >> 2 @ IETF105. >>=20 >> I think we always intended for what you proposed to be true, e.g: = that whats not >> listed in the target work areas would require AD approval to be = chartered. I guess >> we never wrote that explicitly because we had some even more specific >> mentioning of explicit AD approval cases in earlier versions of the = proposed >> charter and those sentence got argued away by reviewers as being too >> procedural and unnecessary for a charter. >>=20 >> Cheers >> Toerless >>=20 >> On Mon, Jul 08, 2019 at 09:23:01AM -0400, Alissa Cooper wrote: >>> Hi Sheng, >>>=20 >>>> On Jul 3, 2019, at 10:39 AM, Sheng Jiang = wrote: >>>>=20 >>>> Hi, Alissa, >>>>=20 >>>> Thanks for your kindly response. I have made a new version (2.0.8) = according >> to your feedback. Explanation in lines below. >>>>=20 >>>> Please see https://trac.ietf.org/trac/anima/wiki/Recharter2019 >>>>=20 >>>>> -----Original Message----- >>>>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>>>> Sent: Wednesday, July 3, 2019 5:13 AM >>>>> To: Brian E Carpenter >>>>> Cc: IESG ; anima-chairs@ietf.org; anima@ietf.org >>>>> Subject: Re: [Anima] Alissa Cooper's Block on >>>>> charter-ietf-anima-01-05: (with BLOCK and COMMENT) >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I???ve been discussing this on my weekly call with the OPS ADs for >>>>> the last couple of weeks and based on the call that we had earlier >>>>> today my understanding is that now would be a good time to = re-review. >>>>>=20 >>>>> Regarding this text: "New work items will be adopted by the WG = only >>>>> if their contributors target them to enter WG last call within a >>>>> number of IETF meeting cycles agreed by the AD.??? >>>>>=20 >>>>> I still don???t get this. It is a very common case that >>>>> contributors think their drafts are going to get through to WGLC = in >>>>> X cycles, and then they end up taking 2X or 10X because some new >>>>> person wanders into the WG or some other work starts up in another >>>>> WG that has an intersection with the work or someone changes jobs >>>>> or any manner of other things. The WG needs milestones with dates, >> preferably at the point of approving the re-charter. >>>>> Those might be missed too, but there might as well not be two sets >>>>> of markers laid down that are potentially going to be missed = rather than one >> set. >>>>=20 >>>> I have just deleted the sentence. It's something the chairs can do = during the >> WG management process. We tried to give draft owners some pressure = not to >> be too slow by adding these text. I do agree this should not be so = rigid as these >> text. So, let's take it out and the chairs will monitor the progress = of WG drafts >> closely. >>>=20 >>> Thanks. >>>=20 >>>>=20 >>>>> Regarding the ???indicative scope of possible work items??? ??? >>>>> this doesn???t address my concern about the WG???s scope. This >>>>> charter is in contrast to the current ANIMA charter, which says: >>>>> "The initial set of work items is limited to the above list to = stay >>>>> focused and avoid 'boiling the ocean???.??? I don???t see the >>>>> rationale for not carrying that forward to the next set of = specific >>>>> work items where WG participants have demonstrated interest and >>>>> intent to carry the work forward. If that is the list of initial = milestone topics >> listed, then limiting to that makes sense to me. >>>>=20 >>>> I have added a specific list of work items into the initial = milestone list. >>>>=20 >>>> Obviously, this initial milestone list does NOT cover all the = topics >>>> that WG participants have showed interests and willingness to work >>>> on. The purpose to have this description of "indicative scope of >>>> possible work items??? are actually two: A, limit the potential = work >>>> items not to be too wide >>>=20 >>> I think my disconnect here is that the list doesn???t actually limit = the WG???s >> scope because it uses the language ???indicative scope of possible = work items??? >> and ???including but not limited to.??? The five areas of work in = this list seem >> broad and large enough to keep the WG busy for quite some time. For = the >> charter to effectively limit the scope I think it would need to say = ???The scope of >> work items is limited to:??? or something like that. >>>=20 >>> Thanks, >>> Alissa >>>=20 >>>> , otherwise, people may take anything has the work "automatic" to = the WG; B, >> to give the chairs a little bit flexibility to adopt new works beyond = the initial >> milestone list. We try to avoid the problem that every time a new = draft comes up, >> it may become a charter revision, particularly, giving the current = re-charting >> process have taken us many months. >>>>=20 >>>> Best regards, >>>>=20 >>>> Sheng >>>>=20 >>>>> Thanks, >>>>> Alissa >>>>>=20 >>>>>> On Jun 10, 2019, at 9:02 PM, Brian E Carpenter >>>>> wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I've taken the liberty of posting an update to the draft charter >>>>>> at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried = to >>>>>> respond to all the IESG comments, and in particular: >>>>>>=20 >>>>>> (a) I deleted Intent from the summarised reference model >>>>>> framework, since the reference model doesn't usefully define = Intent. >>>>>>=20 >>>>>> (b) I tried to make the statement about workload throttling more >>>>>> implementable. >>>>>>=20 >>>>>> (c) I still think that the laundry list of *possible* work items >>>>>> is useful (it helps to define the scope) but I've tried make it >>>>>> clear that it is only the "indicative scope of possible work = items". >>>>>> It really isn't mission creep; all the items mentioned relate >>>>>> directly to the ANI and AF topics. >>>>>>=20 >>>>>> (d) I intentionally removed the reference to not covering machine >>>>>> learning and AI. It isn't suggested anywhere in the reference >>>>>> model, so why even mention it? >>>>>>=20 >>>>>> (e) I fixed nits and tuned the wording in several places. >>>>>>=20 >>>>>> I hope this helps. We really need a new charter before Montreal. >>>>>> WG Chairs and AD, over to you... >>>>>>=20 >>>>>> Regards >>>>>> Brian Carpenter >>>>>>=20 >>>>>> On 02-May-19 08:39, Brian E Carpenter wrote: >>>>>>> Hi Alissa, >>>>>>>=20 >>>>>>> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: >>>>>>> ... >>>>>>>> = ---------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> -- >>>>>>>> BLOCK: >>>>>>>> = ---------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> -- >>>>>>>>=20 >>>>>>>> (1) "Acceptance of work items by the WG will be >>>>>>>> scheduled/throttled so that contributors can target them to >>>>>>>> enter WG last call after not more than a number of IETF meeting = cycles >> agreed by the AD." >>>>>>>>=20 >>>>>>>> I don't understand the implications of this. What happens if = the >>>>>>>> adopted work items have not entered WGLC after the agreed = number >>>>>>>> of cycles? If the answer is anything other than "the WG = abandons >>>>>>>> the work," I don't understand how this is a throttling >>>>>>>> mechanism. A throttling mechanism would need an explicit limit >>>>>>>> on the number of >>>>> adopted work items at any one time, I think. >>>>>>>=20 >>>>>>> I agree that the text is a bit illogical. In a sense it's >>>>>>> unnecessary, because every WG should be matching its workload to >>>>>>> its capacity. Maybe that's all we should say, rather than trying >>>>>>> to describe a >>>>> slightly vague algorithm? >>>>>>>=20 >>>>>>>> (2) The proposed work items is a very large and somewhat >>>>>>>> unbounded list of items, whereas the purpose of writing a >>>>>>>> charter is to scope the work of the WG and hopefully set out a >>>>>>>> realistic work plan that will be accompanied by deployment. For >>>>>>>> a WG that has produced 5 documents in the last 5 years, I think >>>>>>>> the charter needs to more narrowly focus on the most highly >>>>>>>> prioritized work items. Once those are nearing completion, it >>>>>>>> seems as though evaluation of what is needed next based on >>>>>>>> deployment experience would then dictate the next >>>>> set of items for another re-charter. >>>>>>>=20 >>>>>>> I think the point here is that now that the relatively small >>>>>>> number of infrastructure documents are almost finished, the next >>>>>>> stage opens up the possibilities for a much wider range of work >>>>>>> that builds on the infrastructure. The priorities aren't even >>>>>>> obvious. So this goes with the previous point, and to quite some >>>>>>> extent the criteria will be whether the WG has capacity more = than which >> topic has priority. >>>>>>>=20 >>>>>>> That's why there's a bucket list of work items and a short list >>>>>>> of immediate milestones. >>>>>>>=20 >>>>>>> Would this help? >>>>>>>=20 >>>>>>> s/Proposed work items include.../Possible work items include.../ >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> -- >>>>>>>> COMMENT: >>>>>>>> = ---------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> -- >>>>>>>>=20 >>>>>>>> It would be good to see milestones with dates before this gets >> approved. >>>>>>>>=20 >>>>>>>> I think this charter would benefit from an English edit pass >>>>>>>> before going >>>>> out for external review. >>>>>>>=20 >>>>>>> I'll volunteer, when the open issues have been resolved. >>>>>>>=20 >>>>>>>> What is "compounding environment"? >>>>>>>=20 >>>>>>> An excellent question. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>=20 >>=20 >> -- >> --- >> tte@cs.fau.de From nobody Tue Jul 16 06:58:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BF212065C for ; Tue, 16 Jul 2019 06:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 4vLBJfuih7Yw for ; Tue, 16 Jul 2019 06:57:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FBD120618 for ; Tue, 16 Jul 2019 06:57:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45p26D2yV7z14L57; Tue, 16 Jul 2019 06:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563285476; bh=K2PkEyIzfilu6CUZJ9WMPpQ9MXTiCXVzALeNhptyoDM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qF1+JaTCk6Gtl8EjzWnv5LrL+DnBbKyOrTr6vNBAEd1k67Ls9UsER+DOv29Zh3zf+ 8kjDmAIuPlyfzU8oYzucjDBz7jOuNCX+rSjpAffgs7vRNG5raCDoaa7q5yvFKdPSgl VikMm0t6IKX/SU0MomEFo+A94T9q9Xe4nKuMoZ/g= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45p26C5b6hz14L4X; Tue, 16 Jul 2019 06:57:55 -0700 (PDT) To: Eliot Lear Cc: anima@ietf.org, Adam Roach References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 16 Jul 2019 09:57:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 13:58:04 -0000 I can't tell from this whether you agree that it is reasonable to put in some mechanism to address this issue? Yours, Joel On 7/16/2019 9:40 AM, Eliot Lear wrote: > Hi Joel, > > > >> On 16 Jul 2019, at 14:59, Joel Halpern Direct wrote: >> >> I am having trouble connecting your reply with my request. >> Let's take the direct issue first, and then the analogy. >> >> I had suggested a specific enhancement to device behavior. The response was "but that removes the theft protection." It is that form of theft protection that I am objecting to. As far as I can tell, the mechanism I suggested does not break zero touch. It allows someone who controls their network, and who physically controls a new device, to put that new device in their network without asking anyone's permission. >> It does not permit someone with a device, but not network control, from adding that device to the network. It does not permit someone with control of the network, but not physical access to the device, to achieve anything special. So it seems compatible with the goals. > > My apologies I took your statement as something more general than you intended. With respect to this from earlier: > >> I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. > > > That was indeed what we discussed. We just got into means a bit more than perhaps necessary. I’ll point out that it’s always going to be a manufacturer call on how best to do this; and how to transport credentials, and how to keep them safe, even. > >> >> In terms of the analogy, I would have problem with IEtF defining a new protocol that added significant risk to the buyer when they buy from new vendors. >> And existing vendors do go out of businesses. And vendors do end-of-life products. (You can't get a new key to your car because the vendor has stopped supporting that model???) > > I wouldn’t implement a 1:1 mapping products->MASA server function. That seems excessive. And rare is the case when a vendor EOLs a product and then cripples it through an update mechanism. The only issue here is whether a database entry would stay around. > > >> >> Now it may be that the particular approach I suggested won't work. But it seems to me that there needs to be a way for folks to keep using, and to keep re-selling, devices without the support of the vendor. That usage may not get all the zero-touch advantages that supported re-sale would get. But it has to work. And putting the onus for that on the original vendor does NOT seem an effective solution. > > I think you mean, “requiring the vendor to stay around for ever doesn’t seem like an effective solution.†Again, I don’t want to overgeneralize. > > Eliot > From nobody Tue Jul 16 07:02:52 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CC312008B for ; Tue, 16 Jul 2019 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 QVCoUrSinR2C for ; Tue, 16 Jul 2019 07:02:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06E5120086 for ; Tue, 16 Jul 2019 07:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4083; q=dns/txt; s=iport; t=1563285768; x=1564495368; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=HFCrUeJC5Vo4aMEugI5PekS6o2gxIgZEHkXXYUNR1nQ=; b=cjp3jSGixK6jY/brbOIL5IYT1m/x+ZAiKYDzI9Q+w3HlxfAVxw+h2e4+ 8LlRnAsSIiUAwTIaLK4lkf88KvamI7v5lnGNrZt7bjly+rGby42n3ZLfA yBm+iC4+hZyWyN39/hWDO1v7Pn5FsfTYGIvXqPCTbMg3Ss3RL5oQ/dO5U I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABT2C1d/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGDUQEgEiiEHIh7i1QlmH0UgWcCBwEBAQkDAQE?= =?us-ascii?q?vAQGEQAKCXTUIDgEDAQEEAQECAQVthTwMhUoBAQEBAgEjBFIFCwsYIwcCAlc?= =?us-ascii?q?GExkCgwcBgXsPrQB/M4VHhG8QgTQBgVCKJYF/gREnDBOCTD6ELQGDIDKCJgS?= =?us-ascii?q?MOAoSiB2VcgmCG4IfgQyQYRuCLYsKilOOZpMUgwsCBAYFAhWBUgE1RIEUMxo?= =?us-ascii?q?IGxVlAYJBPoI6hACKDz0DMJAzAQE?= X-IronPort-AV: E=Sophos;i="5.63,498,1557187200"; d="asc'?scan'208";a="14302335" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2019 14:02:45 +0000 Received: from [10.61.214.125] ([10.61.214.125]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6GE2hDE015357 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Jul 2019 14:02:44 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FB8A8D25-C496-4762-B74F-34F71FC06571"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 16 Jul 2019 16:02:43 +0200 In-Reply-To: Cc: anima@ietf.org, Adam Roach To: "Joel M. Halpern" References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.125, [10.61.214.125] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 14:02:50 -0000 --Apple-Mail=_FB8A8D25-C496-4762-B74F-34F71FC06571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2019, at 15:57, Joel M. Halpern wrote: >=20 > I can't tell from this whether you agree that it is reasonable to put = in some mechanism to address this issue? I think I do because I proposed such a mechanism up thread. Eliot >=20 > Yours, > Joel >=20 > On 7/16/2019 9:40 AM, Eliot Lear wrote: >> Hi Joel, >>> On 16 Jul 2019, at 14:59, Joel Halpern Direct = wrote: >>>=20 >>> I am having trouble connecting your reply with my request. >>> Let's take the direct issue first, and then the analogy. >>>=20 >>> I had suggested a specific enhancement to device behavior. The = response was "but that removes the theft protection." It is that form = of theft protection that I am objecting to. As far as I can tell, the = mechanism I suggested does not break zero touch. It allows someone who = controls their network, and who physically controls a new device, to put = that new device in their network without asking anyone's permission. >>> It does not permit someone with a device, but not network control, = from adding that device to the network. It does not permit someone with = control of the network, but not physical access to the device, to = achieve anything special. So it seems compatible with the goals. >> My apologies I took your statement as something more general than you = intended. With respect to this from earlier: >>> I have assumed that what we needed is the ability for a buyer, who = has physical possession of the device, and possibly some simple (non = cryptographic) credentials provided by the seller to force the device to = reset what it thinks it is part of, and to emit in some accessible form = the information the buyer needs to be able to make this device part of = his network, using his authentication servers, etc. >> That was indeed what we discussed. We just got into means a bit more = than perhaps necessary. I=E2=80=99ll point out that it=E2=80=99s always = going to be a manufacturer call on how best to do this; and how to = transport credentials, and how to keep them safe, even. >>>=20 >>> In terms of the analogy, I would have problem with IEtF defining a = new protocol that added significant risk to the buyer when they buy from = new vendors. >>> And existing vendors do go out of businesses. And vendors do = end-of-life products. (You can't get a new key to your car because the = vendor has stopped supporting that model???) >> I wouldn=E2=80=99t implement a 1:1 mapping products->MASA server = function. That seems excessive. And rare is the case when a vendor = EOLs a product and then cripples it through an update mechanism. The = only issue here is whether a database entry would stay around. >>>=20 >>> Now it may be that the particular approach I suggested won't work. = But it seems to me that there needs to be a way for folks to keep using, = and to keep re-selling, devices without the support of the vendor. That = usage may not get all the zero-touch advantages that supported re-sale = would get. But it has to work. And putting the onus for that on the = original vendor does NOT seem an effective solution. >> I think you mean, =E2=80=9Crequiring the vendor to stay around for = ever doesn=E2=80=99t seem like an effective solution.=E2=80=9D Again, I = don=E2=80=99t want to overgeneralize. >> Eliot --Apple-Mail=_FB8A8D25-C496-4762-B74F-34F71FC06571 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXS3ZAwAKCRBugA9nE248 uCkXAKCDmMaODk5Wq2FzlGtd6p0hlRZLSwCg505AtVeTDJzfbrzKiZQu/9yOwOc= =fmnv -----END PGP SIGNATURE----- --Apple-Mail=_FB8A8D25-C496-4762-B74F-34F71FC06571-- From nobody Tue Jul 16 09:58:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6987212022A; Tue, 16 Jul 2019 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sN_fssUmlE3u; Tue, 16 Jul 2019 09:58:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C120A120173; Tue, 16 Jul 2019 09:58:21 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A44E13808A; Tue, 16 Jul 2019 12:58:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3BE50B52; Tue, 16 Jul 2019 12:58:20 -0400 (EDT) From: Michael Richardson To: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] ACP SRV.est example X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 16:58:27 -0000 --=-=-= Content-Type: text/plain I suggest that EST servers are never on port 80, and are likely on port 443, or another port. 6.1.4.1. GRASP objective for EST server ACP nodes that are EST servers MUST announce their service via GRASP in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], section 2.8.11 for the definition of this message type: Example: [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, ["SRV.est", 4, 255 ], [O_IPv6_LOCATOR, h'fd89b714f3db0000200000064000001', TCP, 80] ] Figure 3: GRASP SRV.est example -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uAisACgkQgItw+93Q 3WU89wgAraIlpLY5arZO+YwuoX7F2OJs5UGN0GSbWTHaQtYy0BKb8EeKbc4/1nMX rQbeLt2vFrJ45TJj/KOrXyJi29He1PKWcwh8lktCep9N0z+wQTp0v7sJF5fKpHWH bdbWPzt/BkXAvt/T/DfnvSIQkfD/XcDwxBG2KGZ2Rk4mTLNyB74rjz1WMRqvQZvs Zl7YFv2Q52m/3U3F+Qrv2Cvjdbq7V86tl9l4djlUvJElpvqS5sR7hlnVkSmXW1Io wTgBqPCHNYaE+XSF8Nzhi0Mh6mGDfO9GGewcnmN7qbv/3JWHKZ1wXyRiXzeWPTPM vB3DT+gdjCp+SwVi6v0bTxbCqwt+0Q== =yxJ6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 10:01:56 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84141209C7; Tue, 16 Jul 2019 10:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iezmO0morotO; Tue, 16 Jul 2019 10:01:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D8E120088; Tue, 16 Jul 2019 10:01:52 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 32BA03808A; Tue, 16 Jul 2019 13:01:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C4ED7B52; Tue, 16 Jul 2019 13:01:51 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> References: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:01:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {I almost hit the 'n'ext key on this email when I read you had No Objection... I wonder if the DT should link the comments in the DT to the thread that results} Mirja K=C3=BChlewind via Datatracker wrote: > I agree with Alissa's discuss that the conclusion of section 10(.3) > should be to recommend a manual configuration mode. Also with respect okay. > to section 10.2: if ownership is "enforced" by the manufacturer, there > should also probably be a way for the buyer to check if ownership was > transferred by the saler during the re-sale process. So you are asking for an additional API from the JRC to the MASA. It would need to include something like: a) a POST from selling-JRC to MASA to ask MASA for if a resale would be gra= nted. This could result in some statement that the seller could show to the buyer that would validate that the transaction can occur. b) a POST from selling-JRC to MASA to indicate to whom the sale was made, this would have to include some reference to the buyer. c) a GET from the selling-JRc and also buyer-JRC that would ask who the current owners is supposed to be. (c) could in theory be done with the auditlog, provided that the (b) process installed the buyer as an authorized entity that could query the auditlog. It would probably be better to have the MASA do the thinking here, rather than the JRC. I can imagine creating such APIs. There probably needs to be some buyer-JRC/seller-JRC APIs, or at least conventions. This could easily beco= me a rathole attracting all sorts of online sales API. Were this to be added = to this document, or to an extension document, I'd want to have significant involvement from some people who build financial/sales systems, or at least From=20the operations divisions of some buyers (operators) and sellers (ven= dors). > Two other small comments on more load related points: > 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid > head of queue problems wherein an attacker running a fake proxy or > registrar could perform protocol actions intentionally slowly. The > pledge SHOULD continue to listen to for additional GRASP M_FLOOD > messages during the connection attempts." One minor comment: Maybe > also say explicitly, while running in parallel, one should not send a= ll > initial messages at exactly the same time but pace them out (e.g. one > every 3 secs) to avoid network overload when initial connectivity is > very constraint. I take your point. In the ANIMA ACP situation, please think about the situation as being a multiport BFR with three+ 100G fiber connections to other cities. Or, one or more ports plugged into some (unmanaged or probably outsourced) L2 fabric t= hat has multiple other ACP devices on it. > 2) sec 4.3: " It must be sufficiently low that the aggregate amount of > periodic M_FLOODs from all EST servers causes negligible traffic acro= ss > the ACP." I know this is a little bit a blurry requirement but I wou= ld > still like to see a MUST here. Or maybe give an upper bound for the > maximum frequency, e.g. MUST NOT send more than once per minute...? N= ot > sure it there is a reasonable value here. I'm hesistant to write anything specific here. There are two reasons. One is that we really don't have any experience running ACPs yet, or how mu= ch bandwidth will typically be available, and we also don't know how many JRCs a typical operator might deploy. The second reason is that I think that this should really be dealt with in: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ (or mabe https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/) ACP section 6.1.4.1 defines an M_FLOOD for the SRV.est. This is not necessarily the JRC, btw, as certificate renewal might be performed by a different system than enrollment. It does say: The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds. The frequency of sending MUST be such that the aggregate amount of periodic M_FLOODs from all flooding sources cause only negligible traffic across the ACP. I will copy this text. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uAv4ACgkQgItw+93Q 3WWFzwgAm9WFzfN1Jr+pDJTXvgzXOl8RUkDWFZCqHCVVz+o5b9KJmLP7KRVyMxip qJ4XQLTR1kdrF8wCY71Z6JVjfNDdfBxHqSsy7TtHyg3u0y1ZHpnkAvZ4640L587D emmEowPLPnVL8UbLUwLRbC6Th2PnSIrNn2Y9guRtnFXWF8S/5TegdIfBHKKX4+B4 gm+VWzvEPMs1keETCA17WuxnkG9dNAvz/Qybjqd+1rywVRTcaHGvxI3qTKgrlMwO 496Fttxw+LXxlhPcJchsv8bCRyNYnXiqloIVCOdBoYBtTogHkcuPgVnijPBJDDw7 +vb91GcgxtH0fEBOGn5PJJMy/LZSrg== =Qf2j -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 10:13:10 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB1120279; Tue, 16 Jul 2019 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yv4YGVP1ZvEV; Tue, 16 Jul 2019 10:12:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFC412090A; Tue, 16 Jul 2019 10:12:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B6933808A; Tue, 16 Jul 2019 13:12:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3F5FAB52; Tue, 16 Jul 2019 13:12:54 -0400 (EDT) From: Michael Richardson To: Alexey Melnikov cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:12:58 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov via Datatracker wrote: > 1) In Section 5: > o In the language of [RFC6125] this provides for a SERIALNUM-ID > category of identifier that can be included in a certificate and > therefore that can also be used for matching purposes. The > SERIALNUM-ID whitelist is collated according to manufacturer trust > anchor since serial numbers are not globally unique. > I think now you are just inventing things. Please define what exactly > SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed. https://github.com/anima-wg/anima-bootstrap/commit/2f4cee70fc583c60a4589c983043a346ac0145ea new text reads: This extends the informal set of "identifer type" values defined in to include a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. As noted in that document this is not a formal definition as the underlying types have been previously defined elsewhere. The SERIALNUM-ID whitelist is collated according to manufacturer trust anchor since serial numbers are not globally unique. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uBZUACgkQgItw+93Q 3WVxkQf/UJPfFKEsTi9BHDT6Ee4QIaAENy+xpftdY9ucM7kRUWVgpthjf1ODeWqJ n3N1wxkfdlnTFhIwPBpu29hd69LIHlA2FLw5/gkr1vPFd/sbN+OCZQq45bRgiILp FXjPbtwwE4RyPV807+x+WTNnbpsydsJjH3okHkHGvVoTkvFk0GEx8qAIfZYca2fj hwTMIvlQhQnOopiqcncmpJJ/Cfk4oCpz9QuXjHebXxKwiCiaOMp7n19H6r9jBlnb MnAQeSslXXPmLdI0IoiD4pLb/TvgXqKmMx3skRUjCC3Encu6EULRvZUKq+5WAdFP yWnhTEaCbXkNa9a5aj573Q2fAQDmMw== =ork6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 10:16:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C6F12082E; Tue, 16 Jul 2019 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7xCi6evvUfqi; Tue, 16 Jul 2019 10:16:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BA7120A3B; Tue, 16 Jul 2019 10:16:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 72F593808A; Tue, 16 Jul 2019 13:15:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18FCEB52; Tue, 16 Jul 2019 13:16:00 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: Alissa Cooper , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <20190711150819.lafanrg3326f557l@faui48f.informatik.uni-erlangen.de> References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com> <406.1562813786@localhost> <5BC8F1BD-C039-4066-8323-6E82D3AC4F1D@cooperw.in> <20190711150819.lafanrg3326f557l@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:16:04 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> And if the consumer needs to fallback to some non-BRSKI mechanism he >> is expected to bootstrap the device via serial console himself? Trying >> to see if I understand the scope limitations explained in Section 9. > Non-BRSKI operators have to prequalify by showing their knowledge of > serial port console operations and morse code. (do i have to say > *kidding* ?) > How about: > The zero-touch mechanism presented in this and the ACP document > represents a signficiant efficiency: it avoids the need to ship devices > to secure locations to provision them before deployment or to ship > senior experts to remote and often insecure deployment locations to > provision devices on-site with mechanisms as antiquated as craft serial > consoles. It seems to me that this belongs at the end of 1.0, just prior to 1.1? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uBk0ACgkQgItw+93Q 3WVV2Af/ZP5CcBz47xEbVwgOME2nM9i43JyLMvXviuASGWM6EQeq2jiKnwd/oOcB v7vWoextDyDfLWgJfsx5qjQxL2SYL9/3K+u8h4sxZfl4aoJpGT0Kt+BJpLos5uqg ZdWP9600SZIaLKe/ZbF2PtOnKkcHkkWB4c3N9nxXGyUEJ/S+K9OvAbsdvEbPVy3G 7ld3V1FcpFkIdX9afzLowAnhGCPFFJ17P+bq5Id6JEITbQxPu1gkkRIGrsEnmuA8 GtgUrk9qWs5SMF54W6G5/IAVryw7THEkU+BTxHJYyOrxDaSrp1CbD5HoC4OXzRpP LUbJyDUdcrI+ByDqzvcm2rpTgS9x0g== =VCBR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 10:55:47 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA0120C00; Tue, 16 Jul 2019 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 m1-82cltp8nv; Tue, 16 Jul 2019 10:55:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8AA120BEE; Tue, 16 Jul 2019 10:55:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B51C33808A; Tue, 16 Jul 2019 13:55:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60A0BB52; Tue, 16 Jul 2019 13:55:32 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org In-Reply-To: <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:55:39 -0000 --=-=-= Content-Type: text/plain Adam Roach wrote: mcr> *** but manufacturers have to want to do it *** adam> I completely agree with everything you just said, and sincerely adam> thank you for the work you've done in this area. I think where our adam> perspectives might diverge is our beliefs about what *we*, the adam> IETF, can do about it in this specific case. adam> The IETF, as a matter of practice, includes normative statements in adam> documents all the time regarding processes that conformant adam> implementations "MUST" follow for the sake of security. In many adam> cases, the protocol works just fine if implementors ignore these adam> requirements, which means that implementation of them resolves to adam> exactly one thing: manufacturers have to want to do it. ... adam> The smallest change that would satisfy my concern would be a statement adam> that says that devices conformant to this specification MUST contain a adam> local means of bootstrapping that does not rely on any specific server adam> being available. I propose to add text to section 9: Applicability to the Autonomic Control Plane that makes implementing something from 7.2 a normative MUST. As specified in the ANIMA charter, this work "..focuses on professionally-managed networks." Such a network has an operator and can do things like install, configure and operate the Registrar function. The operator makes purchasing decisions and is aware of what manufacturers it expects to see on it's network. Such an operator is also capable of performing bootstrapping of a device using a serial-console (craft console). The zero-touch mechanism presented in this and the ACP document represents a significiant efficiency: in particular it reduces the need to put senior experts on airplanes to configure devices in person. There is a recognition as the technology evolves that not every situation may work out, and occasionally a human may still have to visit. In recognition of this, some mechanisms are presented in . The manufacturer MUST provide at least one of the one-touch mechanisms described that permit enrollment to be proceed without availability of any manufacturer server (such as the MASA). I have additionally, added a fourth example to section 7.2: 4. A craft/serial console COULD include a command such as "est- enroll [2001:db8:0:1]:443" that begins the EST process from the point after the voucher is validated. This process SHOULD include server certificate verification using an on-screen fingerprint. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uD5EACgkQgItw+93Q 3WV7pAgAkUdNmfV2qfEZIdWNoccm81Zcs73X/tTwipr68kbu/9yShgVit5y8atb9 kTWge5xtY4jDHpzbbLDdDGRQwpxp6D71WKbdrNPqkFF9DeiQVsEqgpv/QChwjekN PP5AU0o2bcAA7aQQS54pZmcCBiF2zNYwk6xetLlaier88MXUfv5rI1K2BoE84NAd A9/rsqVBgVx/glTtnG9hMS/4yKICJ9Ay27COHtEK7iXllJi26fbQFV58gbR2RYaA MR0HY4KvwmdgHdB+i7rt1VLZ65sqXFDBc+QuChVVnCIVHzG2zsmFwOGnaIW50wNE ak8Q3NgcacITkcx32kgerwXjyrKjcA== =vaFX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:05:36 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B0B120124; Tue, 16 Jul 2019 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Griu8fnSF5oF; Tue, 16 Jul 2019 12:05:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C57112011F; Tue, 16 Jul 2019 12:05:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C7703808A; Tue, 16 Jul 2019 15:05:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56BC4B52; Tue, 16 Jul 2019 15:05:23 -0400 (EDT) From: Michael Richardson To: Ted Hardie cc: Adam Roach , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <19180.1562875321@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:05:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ted Hardie wrote: > Howdy, > I would personally not suggest using IRIs here, given that the scheme > (https) is expected to retrieve a resource at a well-known location a= nd > thus will always have to be mapped to a URI to do the retrieval (rath= er > than used in a string comparison or something similar) . RFC 5280, > which this cites, actually goes through the steps pretty well, and I > think the complexity there demonstrates the advantage for constrained > devices of always using the URI form. I have changed the references from IRI to URL, and the components from iauthority to 'authority'. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uH/MACgkQgItw+93Q 3WVLzggAk11bjHCdemASqxGfzXo6gDnbku2BfwuXXIHfjzeqckj5LW/flUO+Llcq 6DnnnepAc3QbiRjTvkqJ+I8M1BCUA7DWqCN6C82GyZtP1t0MnYxC0yqWiskLRbSq 8bk4NAb1wMi78Pu8KwvPHXAwF7CnWpuU7nhWjHIJts4OB/5v4Pfg4c2/K/q3+fs2 Mj1xZQ4UYwicvsyE5Bj9DUPdCo8LXynSow5odCIXmt+JYr1mJtxCY/fV0s8SY/Hb p8rCtoBl+/AHEW6/eayg7L3tjGcu7aFhUrK9VYbz7vqSoloz+4dCwEiGGwvyyYUZ 97LFxPObkT22Z2pCht0irkCo5R8bIw== =K2M4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:08:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B990112023D; Tue, 16 Jul 2019 12:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GnbaY-PmB5lJ; Tue, 16 Jul 2019 12:08:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57D1201D8; Tue, 16 Jul 2019 12:08:41 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 401543808A; Tue, 16 Jul 2019 15:08:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 03863B52; Tue, 16 Jul 2019 15:08:41 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <20219.1562875510@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:08:45 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adam Roach wrote: > "HTTP", but even that may be unnecessary in this case. > REST means... something. Exactly what depends on who you ask. In > practice, the least controversial thing to do is avoid the term; and, > if you're trying to describe a specific quality (e.g., idempotence), > say so explicitly. I have removed the two occurences of "RESTful", and in the place where we use 201-Created w/Location:, I mentioned that it is the idempotency that is probably important. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uILgACgkQgItw+93Q 3WXVYAf/dMf72ia59KvsX8FoYieu3Zp5HfnMNvizbZ0rtQwH7aNMQgIKSw1ytBfV G6SjHGvTSUxl+MqrpAsXyIKpOE16klcNn4VJlDacnxz0StfATcwk0y73e5Rilf5K VeI77RMWCs6mErebCjDZNgyQq7+ORG1dd65SLqCz8TnwgOjnKDS7o2SrPwPOJ6b2 JRFcGCTXgz3i2zKC7j4np/p6AVp9MmAQIO65DUk9xBtmYdMU5uXMtHloxfFExo77 +Dt+mGQ25Iz5oWLgKMSU4/rCZB318outYATK0tZwCVbrAnu6aGaJe0O7HQaqFosk yj722wGElYGVhFk3FaAeYKCmofFEnA== =LfNY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:29:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C553B12011B; Tue, 16 Jul 2019 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Q_Syjn4etMTM; Tue, 16 Jul 2019 12:29:37 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5D7120041; Tue, 16 Jul 2019 12:29:37 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id s7so41754729iob.11; Tue, 16 Jul 2019 12:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8rDSXVVDbqdnGE8ETixHTuycLotLltcXDJVWY7pS60A=; b=FMe2vFvk4/okMLbHG0C9gn2feODdOCDv6+69tUXQcfhpTU89E+YWYLvFwCuRHTJ74R yXc7fbM29GZxZWoDddZo9scKrt7XcAn74Dz2zUdwTTROmjMk1h33gsJnI2CVp2DYt7yk ThN0O/jfl6v8l2KjGvFgfOqMNz9SpP0ZATmmSz68jFDwYHGQ6lceLJaXBQ0yIR9QR2hX iK4T//L2QwQEjQhb9T9l6Ub5DKmEdP9xuNLdnk8oRxKDaDs3tMaLKyA+8waKXU3erB0i 6zOeEJ6ckhGbUsZQHsbAcyByEXjn/5VP49A4zoatkXCJ8Ts+vjthUNsSi7RxPAzNSu3e 28Gw== X-Gm-Message-State: APjAAAUKetw0pDsS2FwIxx+h8IR7I7YZCUYSj0Lu9aUXuOOKqOXbkRqV v1zrhrfvNGTv7crhK0FJsL1+2RiV0aNPLPWqWls= X-Google-Smtp-Source: APXvYqwtE49Znna0bfi+ZqkryOhH2zePFNecRXIExHExnwc0frO2IbQ2TWGSMoQZLXj6ttHhFfP0Rbbn0K2zDHrw9uc= X-Received: by 2002:a5d:9613:: with SMTP id w19mr11004901iol.140.1563305376263; Tue, 16 Jul 2019 12:29:36 -0700 (PDT) MIME-Version: 1.0 References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <19180.1562875321@localhost> <26415.1563303923@localhost> In-Reply-To: <26415.1563303923@localhost> From: Barry Leiba Date: Tue, 16 Jul 2019 15:29:25 -0400 Message-ID: To: Michael Richardson Cc: Ted Hardie , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:29:39 -0000 > > I would personally not suggest using IRIs here, given that the scheme > > (https) is expected to retrieve a resource at a well-known location and > > thus will always have to be mapped to a URI to do the retrieval (rather > > than used in a string comparison or something similar) . RFC 5280, > > which this cites, actually goes through the steps pretty well, and I > > think the complexity there demonstrates the advantage for constrained > > devices of always using the URI form. > > I have changed the references from IRI to URL, and the components from > iauthority to 'authority'. I think the best thing for IETF documents is to use "URI" (rather than "URL"), and to cite RFC 3986. The W3C, via the WHATWG, is (re-)defining "URL", and we *could* cite that work. That would not be my preference here. Barry From nobody Tue Jul 16 12:35:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664E12011B; Tue, 16 Jul 2019 12:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oiO5hKIXoBVT; Tue, 16 Jul 2019 12:35:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBBC120114; Tue, 16 Jul 2019 12:35:36 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 5FA3B3808A; Tue, 16 Jul 2019 15:35:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1FBBFB52; Tue, 16 Jul 2019 15:35:34 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: Brian E Carpenter , "Joel M. Halpern" , Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org In-Reply-To: <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:35:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adam Roach wrote: > On 7/15/19 3:38 PM, Brian E Carpenter wrote: >> On 15-Jul-19 16:45, Joel M. Halpern wrote: >>> I presume I am missing something basic. I have tried to follow this >>> discussion, as it seems to be about a critical aspect of whether the >>> BRSKI work is acceptable. >>>=20 >>> I have assumed that what we needed is the ability for a buyer, who >>> has physical possession of the device, and possibly some simple (non >>> cryptographic) credentials provided by the seller to force the devi= ce >>> to reset what it thinks it is part of, and to emit in some accessib= le >>> form the information the buyer needs to be able to make this device >>> part of his network, using his authentication servers, etc. >> Yes, but *not* a solution that works if the device is stolen. > I'm actually a little ambivalent with respect to this use case. For t= he > kind of devices that the document purports to be targeting, I would > imagine that theft is in the range of parts-per-thousand (or lower) as > compared to things like post-bankruptcy liquidation. If you can fix t= he > first without ruining the second, great. I mostly agree! While a great deal of the ACP use case deals with physically large devices which are in datacenters, in locked cages, there are aspects where we are dealing with devices in significantly more vulnerable places. This ranges From=20FTTN equipment in a box on a nearby curb, to ISP owned CPE devices physically in people's homes [%]. But, the more vulnerable devices are also of lower dollar value. We are mandating vendors to provide *A* way, but that doesn't have to be an enable prompt with no password. There could be a one-time-password on the port.=20 S/Key would fine given the initial seed provided in the packaging. draft-wkumari-opsawg-sdi would also work, the initial configuration could include "est-enroll [2001:db8:0:1]:443". [%] the CPE CMTS use case is the domain of TR-069. I don't know what DSL providers do, some have service PPPoE username/password that they use. Let other use cases write different requirements for access. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uJwUACgkQgItw+93Q 3WWtZwgAgQ0TzElAXH1KPZVBqElWzRwPoj2nYj5Scr1rI341oO/X1O0AQlscL0tN dxHLht8kGRg2g90deExmLxMFPDZpSLSjC99rH6KraWOBABz/lMTB8GHCIjboL8fu dtArxpKkhvCoV7h/1TI+83W2YhwPQHRJWjjdbnOGYXQd6mzagr9LpMD3oAscxFnT 3Cqs57mZUvLEghDORU2wAdbimZW9v6rYrjb2ZO1SWAP/IffaCE8m8FhGZwziCXUn MeT0AWZqSF4HjkkKnK8CbyG0s2eEOG0eN8ou0UTUO6JS6DH7DJhgW4pq5/+jo8sA vZm1en8/TpzJmHrOnSEjgpd7WPvZng== =OFcb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:47:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700412067A for ; Tue, 16 Jul 2019 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jOuT4ImaMl07 for ; Tue, 16 Jul 2019 12:47:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1690E120610 for ; Tue, 16 Jul 2019 12:47:14 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B7F603808A; Tue, 16 Jul 2019 15:47:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8237DB52; Tue, 16 Jul 2019 15:47:13 -0400 (EDT) From: Michael Richardson To: Joel Halpern Direct cc: Eliot Lear , Adam Roach , anima@ietf.org In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:47:23 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joel Halpern Direct wrote: > It allows someone who > controls their network, and who physically controls a new device, to > put that new device in their network without asking anyone's > permission. Right, get your "blue cable" out, connect it to the serial console, bring up minicom, and tell the device to enroll. Verify the registrar's certificate when prompted, perhaps. You can still use GRASP to find the Registrar, and all the rest of the ACP mechanism.... or not. That's been in section 7.2, but the complaint was that it was not normative. So, we have added in section 9, for the ACP use case, that implementing something is a MUST. I don't think it will work for lightbulbs, but whomev= er writes that Applicability Statement will have to cope with that. (it will be me: I have a document in 6tisch, which is that document. I would appreciate your thoughts on what might be acceptable there) BTW: A number of router manufacturers have BRSKI-like mechanisms already, b= ut they only really work when you drink all their koolaid, and build your network exclusively with their equipment. At one ISP that I consult for, they wound up turning the super-duper auto-join management system off because it ate a= ll of a very high end VM platform, and they just couldn't afford that at the time... Maybe cross-vendor mechanisms will result in some competition and some better products.=20 > Now it may be that the particular approach I suggested won't work. B= ut > it seems to me that there needs to be a way for folks to keep using, > and to keep re-selling, devices without the support of the vendor. > That usage may not get all the zero-touch advantages that supported > re-sale would get. But it has to work. And putting the onus for that > on the original vendor does NOT seem an effective solution. As long as vendors support blue cables, and are willing to provide firmware updates, I don't see any change.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uKcEACgkQgItw+93Q 3WX5VggAguQL1pVpop1b6W4tNYUDHDGc6EjnnsdvgJvGWvvtpUgLwuuwF1XpELnm IQoIPWDu9oDXAsEAZ0dDV4E3s53zKi+1JZMaBLgh8Zdz3KTATAHtX+NZNrmM0lPr kL36n3iUHK1alXl/hWBZRlBxA1VX+KvVPbBiN6BV+jiSHDwKGCqk86atSlzLWPut OZhZ1+/SiFKfWXBUAMksDcjCImy6ZuIWk5FXmdzf1DynMTyIkhuWZDfjeRuVZXbc zK4AB8xmq0C3x+F2OMgGK/algxz0Pksqr+7glWu9MJyR5gm9e7hwUV40C455Btkv gtdq2ZK3ZoJ8bh+p7j36ZoJgEHrqgg== =Bgfj -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:49:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375712004C for ; Tue, 16 Jul 2019 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 gBBna0VrNCfz for ; Tue, 16 Jul 2019 12:49:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F328120041 for ; Tue, 16 Jul 2019 12:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45p9vy1Q0zzpj3h; Tue, 16 Jul 2019 12:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563306574; bh=NxE+OKkKGhPZ7j8CutkJJJbR4tfsmtucO23gcTV8yy4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P24fbe1HY44SzMDVa2yFeBsLGFK8exCxz8D46xJC8180I78VP/fyiPrStG46IfOmQ i/GmAhbd8tU6wAasQjgM7d4hTfXSITMAlTKhDwOlBggrg5G+0g5Zq4vzQqcW7kyYO6 54BBAwYU1ajfo/xhCOkRpkbhLjRlGfqvIfLAHd4g= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45p9vw63qKzpghP; Tue, 16 Jul 2019 12:49:32 -0700 (PDT) To: Michael Richardson Cc: Eliot Lear , Adam Roach , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <5240.1563306433@localhost> From: "Joel M. Halpern" Message-ID: Date: Tue, 16 Jul 2019 15:49:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5240.1563306433@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:49:36 -0000 Thank you Michael. I saw the proposed change in section 9. I wonder if that is hiding the MUST, since the mechanisms are in section 7... Having said that, I can live with it as you have proposed. Yours, Joel On 7/16/2019 3:47 PM, Michael Richardson wrote: > > Joel Halpern Direct wrote: > > It allows someone who > > controls their network, and who physically controls a new device, to > > put that new device in their network without asking anyone's > > permission. > > Right, get your "blue cable" out, connect it to the serial console, bring up > minicom, and tell the device to enroll. Verify the registrar's certificate > when prompted, perhaps. > > You can still use GRASP to find the Registrar, and all the rest of the ACP > mechanism.... or not. > > That's been in section 7.2, but the complaint was that it was not normative. > So, we have added in section 9, for the ACP use case, that implementing > something is a MUST. I don't think it will work for lightbulbs, but whomever > writes that Applicability Statement will have to cope with that. > (it will be me: I have a document in 6tisch, which is that document. I would > appreciate your thoughts on what might be acceptable there) > > BTW: A number of router manufacturers have BRSKI-like mechanisms already, but they > only really work when you drink all their koolaid, and build your network > exclusively with their equipment. At one ISP that I consult for, they wound > up turning the super-duper auto-join management system off because it ate all > of a very high end VM platform, and they just couldn't afford that at the > time... Maybe cross-vendor mechanisms will result in some competition and > some better products. > > > Now it may be that the particular approach I suggested won't work. But > > it seems to me that there needs to be a way for folks to keep using, > > and to keep re-selling, devices without the support of the vendor. > > That usage may not get all the zero-touch advantages that supported > > re-sale would get. But it has to work. And putting the onus for that > > on the original vendor does NOT seem an effective solution. > > As long as vendors support blue cables, and are willing to provide firmware > updates, I don't see any change. > From nobody Tue Jul 16 12:53:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4647D12013D; Tue, 16 Jul 2019 12:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ydAW_wW9xM7G; Tue, 16 Jul 2019 12:53:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52D9120199; Tue, 16 Jul 2019 12:53:26 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id C9AC53808A; Tue, 16 Jul 2019 15:53:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 92937B52; Tue, 16 Jul 2019 15:53:25 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org In-Reply-To: <38C82875-AFA7-476B-A147-1433D10C2D20@nostrum.com> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> <38C82875-AFA7-476B-A147-1433D10C2D20@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:53:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adam Roach wrote: >> On Jul 15, 2019, at 02:39, Eliot Lear wrote: >>=20 >> This give you the option for that not to be the case (people needn= =E2=80=99t >> worry about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric >> going out of business anytime soon, for instance > When I started IETF work, Nortel would have been on your list. It's a really good example, and I use it all the time when talking about th= is work. I bought some very cheap shares just before they stopped trading, because I thought that they might get bailed out. So I get updates on where it is in the bankruptcy process. It's still not over. The company technically still exists. Their VPN boxes are amazingly, still in use in my town. I want to point out that this is why we wrote Manufacturer *AUTHORIZED* Signing Authority. We envision that this is a process that can be outsourced, and that customers will insist that it is escowed. 25 years ag= o, when I worked in one of the first firewall companies, dead 20 years now, I regularly provided escrow tapes. It's almost never worth the customers' money to use them, but I'm sure someone has used them. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uKzUACgkQgItw+93Q 3WW5Lgf/XFpj/PDT84f+pEW+1TiqaoFEYLrEdaqLhZT2iW31YJHhZDKNlxiqsVnH +EqOR/0lJ8I/6o0oI7+jS9L/TByJUi2a5GhOCCyZGctB2vPF64lZyhR+j88+YxvK cwNwKWPH/Pw1V9zz98r6biOxAQpLh9olOaiGGI7TgdCpZblPtXm7V4T7+Toz5hHO 8aChBuhEYZVCGEFNdIvCh1LCANbu/FaWZd4GT1lBkgIx2TSHvfb0CTnEP1nU9N4U Zm+sdSKCTEoQE2XobsxZjs6khK8uhSsLjhmu5aI/n8kV6fs3PzldB6Mw5qlrsTd3 2hSyE4JeTXteNj/8A7DieFSgqVCP5A== =TjMB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 12:58:58 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841D1200C5; Tue, 16 Jul 2019 12:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 C9Zyvy-OV3PJ; Tue, 16 Jul 2019 12:58:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936991200C4; Tue, 16 Jul 2019 12:58:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CB8A23808A; Tue, 16 Jul 2019 15:58:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 914E0B52; Tue, 16 Jul 2019 15:58:52 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, The IESG , Toerless Eckert , anima@ietf.org In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 19:58:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> On 13 Jul 2019, at 17:10, Michael Richardson >> wrote: >>=20 >> Signed PGP part >>=20 >> Eliot Lear wrote: >>> I think the simplest way to address the bulk of both Adam=E2=80=99s= and >>> Warren=E2=80=99s concern is to require the device to emit via whate= ver >>> management interface exists, upon request, a voucher that it has >>> signed with its own iDevID. It would have to be nonceless with >>> perhaps a long expiry, and that would cover a number of other use >>> cases as well. That way if the manufacturer goes out of business, = or >>> if the owner wants to transfer the device without manufacturer >>> consent, there is a way forward. >>=20 >> 1) would it have a pinned-domain-cert for the new owner, or would it >> be some kind of wildcard/bearer voucher? > Again, I think this is a matter for the seller, and also a matter for > the seller as to when the voucher is generated, so that it doesn=E2= =80=99t need > to lie around. I was also thinking that this would be the sort of > thing that could be printed out, either in a QR or OCR form, if > necessary. But, the pledge has to be programmed to do the validation we describe. >> 2) what would the management interface be, specifically, how would it >> be secured? > The reason I mentioned CIP and Profinet in a previous message is that > once the device is bootstrapped, if it has a management interface, th= at > is what should be used. Adding new services on a device is > undesirable. This covers the case when the manufacturer becomes > unavailable. However, it should be viewed as a backstop. See below. I am completely unfamiliar with those protocols. I would very much like to define a way to update voucher validation trust anchors in that. > Another way to look at this would be to for the manufacturer to ping > the owner periodically to reconfirm ownership. If the owner fails to > respond, allow another owner to transfer the device. Or=E2=80=A6 sim= ply ping > the owner when a transfer request is made. But these require that the > MASA be present. This is a good sales channel integration point, and might be a win-win for many manufacturers and operators. Why pay for support on devices that are no longer used? Why generate security patches for devices no longer used? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0uLHwACgkQgItw+93Q 3WV4Zwf+OgNWB96eJdVJ/StYXOcMrBKsHaVOLyRUXG7/7jX3F1jI+atBUJoB26Lg JChactWWPpQYTGDh4dWzwx+ODbErj42giPADBr6mqjRsrfEMEJCWb9HWIVYqrl7m OaG2yn6CwKmgwmsgU56uu344CI9ybNm2NXU1ku5SvRJRXyw3BhizHxBoDEQiVwOk rLEi882Q9Rzj1ixH26fCoNR+o2O/G2pnSGN2B43+8XXNE1oMzdQqHKf9aDIo9zHh rwKJb3qLJtjehIMrp563ovoyETOvYZN5h+fubfz+zxArPTCqCAmqRocIDlRrS6/x HxTPyu6A95eYcva+zb2SR6MwEQ3wqQ== =a8H7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 16 13:31:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D6120113 for ; Tue, 16 Jul 2019 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5BeQikQ06opv for ; Tue, 16 Jul 2019 13:31:42 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AE3120041 for ; Tue, 16 Jul 2019 13:31:42 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id w10so9995607pgj.7 for ; Tue, 16 Jul 2019 13:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=izO8fldMWnwL68MK8+py+bB3cZQHt5lu2qI9NpFN4tw=; b=JAHUHRMj0je5CWVzwAnZWfhmrR0oQThSQrAeYW4J+CcmOBHWqXz8T7KjLCcXKu+BTh 5dXgBV78sH2V1HnEHnywbzmZUXuouXrW2ryXtenfgUu2gwoLwlhmge9PoItcKOcIMUpd fH5mYJ9SePVkKjwzIvc2eLMZ61w6X78X9v/8PdxdmseXOjP7N9UQsM4VqfrfIedbBdEX abBZ/Hfeh+b7vNFo2nPqGgLgh/CxQzJmgvdc77vcAYbeYtEh1XKV2dA5NSujoqzZv+jZ IKwH9KA/HHYU8bNHDU2sE4MNfc7BK8ImgMzz/ltuEFlYWqbNDuvJrgEJYqsFaPf9K42b YpzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=izO8fldMWnwL68MK8+py+bB3cZQHt5lu2qI9NpFN4tw=; b=HZD2MwxY5IQysru4eTKv/oMn+mz/Ktt5yOcBrsG1J3iBwA6UsrkaLKrmb2nE3953dF Wf4p8Jvj+FQXWaqKGY/0mjjG8am9lrMS4wvdqir4m8IZsReCzIJx3gItbm3TKehd3iL7 aTZac4I29yz6rIk68y3B5EjM7vBExXKlt10twMAOuStEBYf1VPCzfE/wKJwLEwAyeGB9 cl3hjs42XC5cAb0TqukithZyOi655ucl95VuSxEAzMH3rQDBZZPWitusJPfx0a+e2sJv iz5AapObXZnFiOVtG8wnMEnj6Ee/ITN2g4+bwmRgD8+u2l97qlRo8wAmgLv+09HgIUUC zBRw== X-Gm-Message-State: APjAAAWPrRnklaG1aHPv8SWLoNRwYWq/qp67D/uKnxfWYOtvfMdcQgEp nrlP0lUJy8SRL4pOGI74ObmeRaA2 X-Google-Smtp-Source: APXvYqxpq3D77aMLpkfb2A9fRQKrnwiFFD2xOgYeIl37Ghad2V2C+Qy65Hs/2rR0odp6Yf+7gHkj5g== X-Received: by 2002:a17:90a:8c90:: with SMTP id b16mr38699578pjo.133.1563309102001; Tue, 16 Jul 2019 13:31:42 -0700 (PDT) Received: from [192.168.178.30] (40.226.69.111.dynamic.snap.net.nz. [111.69.226.40]) by smtp.gmail.com with ESMTPSA id c69sm24317694pje.6.2019.07.16.13.31.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 13:31:41 -0700 (PDT) To: "Joel M. Halpern" , Eliot Lear Cc: Adam Roach , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> From: Brian E Carpenter Message-ID: <505f5437-8626-ab42-9eae-f5e1c3ac7a43@gmail.com> Date: Wed, 17 Jul 2019 08:31:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 20:31:45 -0000 Up-levelling the topic a little bit: It seems to me that from the amount of interest and discussion, BRSKI is going to be quite important (or a resounding failure, in which case this is all beside the point). Assuming it's a success, there will inevitably be updates and enhancements. So, I'd prefer that we don't try to solve all problems now. I'd rather get the first version to Proposed Standard next week... Regards Brian Carpenter On 17-Jul-19 01:57, Joel M. Halpern wrote: > I can't tell from this whether you agree that it is reasonable to put i= n=20 > some mechanism to address this issue? >=20 > Yours, > Joel >=20 > On 7/16/2019 9:40 AM, Eliot Lear wrote: >> Hi Joel, >> >> >> >>> On 16 Jul 2019, at 14:59, Joel Halpern Direct wrote: >>> >>> I am having trouble connecting your reply with my request. >>> Let's take the direct issue first, and then the analogy. >>> >>> I had suggested a specific enhancement to device behavior. The respo= nse was "but that removes the theft protection." It is that form of thef= t protection that I am objecting to. As far as I can tell, the mechanism= I suggested does not break zero touch. It allows someone who controls t= heir network, and who physically controls a new device, to put that new d= evice in their network without asking anyone's permission. >>> It does not permit someone with a device, but not network control, fr= om adding that device to the network. It does not permit someone with co= ntrol of the network, but not physical access to the device, to achieve a= nything special. So it seems compatible with the goals. >> >> My apologies I took your statement as something more general than you = intended. With respect to this from earlier: >> >>> I have assumed that what we needed is the ability for a buyer, who ha= s physical possession of the device, and possibly some simple (non crypto= graphic) credentials provided by the seller to force the device to reset = what it thinks it is part of, and to emit in some accessible form the inf= ormation the buyer needs to be able to make this device part of his netwo= rk, using his authentication servers, etc. >> >> >> That was indeed what we discussed. We just got into means a bit more = than perhaps necessary. I=E2=80=99ll point out that it=E2=80=99s always = going to be a manufacturer call on how best to do this; and how to transp= ort credentials, and how to keep them safe, even. >> >>> >>> In terms of the analogy, I would have problem with IEtF defining a ne= w protocol that added significant risk to the buyer when they buy from ne= w vendors. >>> And existing vendors do go out of businesses. And vendors do end-of-= life products. (You can't get a new key to your car because the vendor h= as stopped supporting that model???) >> >> I wouldn=E2=80=99t implement a 1:1 mapping products->MASA server funct= ion. That seems excessive. And rare is the case when a vendor EOLs a pr= oduct and then cripples it through an update mechanism. The only issue h= ere is whether a database entry would stay around. >> >> >>> >>> Now it may be that the particular approach I suggested won't work. B= ut it seems to me that there needs to be a way for folks to keep using, a= nd to keep re-selling, devices without the support of the vendor. That u= sage may not get all the zero-touch advantages that supported re-sale wou= ld get. But it has to work. And putting the onus for that on the origin= al vendor does NOT seem an effective solution. >> >> I think you mean, =E2=80=9Crequiring the vendor to stay around for eve= r doesn=E2=80=99t seem like an effective solution.=E2=80=9D Again, I don= =E2=80=99t want to overgeneralize. >> >> Eliot >> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Jul 16 14:00:01 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9F1200C1 for ; Tue, 16 Jul 2019 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 pVrIw8RY4njN for ; Tue, 16 Jul 2019 13:59:58 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AF6120096 for ; Tue, 16 Jul 2019 13:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45pCTB0cjDzpkS7; Tue, 16 Jul 2019 13:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563310798; bh=q5tY6sxNRK7zCsW0bM+25VgaI91PPl8Gxljjn8QA1X4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TgXBSAMGHp+J4L/jDLCqqsifiXTgUWinCRjdZobzUMxVFlUzux7s9717J0RQjUdv1 OD/seDiDYnCWu5jmoh+8p1AkgO7+5BREJYnqM4wDBKJxEq+TRlupCoBL8uxYxdcYpo JWYzm4lq28SfjRshjylfEzUymHXEHVrXTCo4IUMI= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45pCT84fnGzpkSG; Tue, 16 Jul 2019 13:59:56 -0700 (PDT) To: Brian E Carpenter , Eliot Lear Cc: Adam Roach , anima@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <70FB01AF-08A1-4542-B944-556F51F98E5F@cisco.com> <505f5437-8626-ab42-9eae-f5e1c3ac7a43@gmail.com> From: "Joel M. Halpern" Message-ID: <4a8d4d44-0f25-3143-208c-b2768ffbea04@joelhalpern.com> Date: Tue, 16 Jul 2019 16:59:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <505f5437-8626-ab42-9eae-f5e1c3ac7a43@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 21:00:00 -0000 With the mandates that Michael proposed adding, I can live with advancing the document. Yours, Joel On 7/16/2019 4:31 PM, Brian E Carpenter wrote: > Up-levelling the topic a little bit: > > It seems to me that from the amount of interest and discussion, BRSKI > is going to be quite important (or a resounding failure, in which case > this is all beside the point). Assuming it's a success, there will > inevitably be updates and enhancements. > > So, I'd prefer that we don't try to solve all problems now. I'd rather > get the first version to Proposed Standard next week... > > Regards > Brian Carpenter > > On 17-Jul-19 01:57, Joel M. Halpern wrote: >> I can't tell from this whether you agree that it is reasonable to put in >> some mechanism to address this issue? >> >> Yours, >> Joel >> >> On 7/16/2019 9:40 AM, Eliot Lear wrote: >>> Hi Joel, >>> >>> >>> >>>> On 16 Jul 2019, at 14:59, Joel Halpern Direct wrote: >>>> >>>> I am having trouble connecting your reply with my request. >>>> Let's take the direct issue first, and then the analogy. >>>> >>>> I had suggested a specific enhancement to device behavior. The response was "but that removes the theft protection." It is that form of theft protection that I am objecting to. As far as I can tell, the mechanism I suggested does not break zero touch. It allows someone who controls their network, and who physically controls a new device, to put that new device in their network without asking anyone's permission. >>>> It does not permit someone with a device, but not network control, from adding that device to the network. It does not permit someone with control of the network, but not physical access to the device, to achieve anything special. So it seems compatible with the goals. >>> >>> My apologies I took your statement as something more general than you intended. With respect to this from earlier: >>> >>>> I have assumed that what we needed is the ability for a buyer, who has physical possession of the device, and possibly some simple (non cryptographic) credentials provided by the seller to force the device to reset what it thinks it is part of, and to emit in some accessible form the information the buyer needs to be able to make this device part of his network, using his authentication servers, etc. >>> >>> >>> That was indeed what we discussed. We just got into means a bit more than perhaps necessary. I’ll point out that it’s always going to be a manufacturer call on how best to do this; and how to transport credentials, and how to keep them safe, even. >>> >>>> >>>> In terms of the analogy, I would have problem with IEtF defining a new protocol that added significant risk to the buyer when they buy from new vendors. >>>> And existing vendors do go out of businesses. And vendors do end-of-life products. (You can't get a new key to your car because the vendor has stopped supporting that model???) >>> >>> I wouldn’t implement a 1:1 mapping products->MASA server function. That seems excessive. And rare is the case when a vendor EOLs a product and then cripples it through an update mechanism. The only issue here is whether a database entry would stay around. >>> >>> >>>> >>>> Now it may be that the particular approach I suggested won't work. But it seems to me that there needs to be a way for folks to keep using, and to keep re-selling, devices without the support of the vendor. That usage may not get all the zero-touch advantages that supported re-sale would get. But it has to work. And putting the onus for that on the original vendor does NOT seem an effective solution. >>> >>> I think you mean, “requiring the vendor to stay around for ever doesn’t seem like an effective solution.†Again, I don’t want to overgeneralize. >>> >>> Eliot >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Tue Jul 16 14:28:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5E120136; Tue, 16 Jul 2019 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 gkFBHhfibM6q; Tue, 16 Jul 2019 14:28:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63A112007C; Tue, 16 Jul 2019 14:28:34 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6GLSNZm012043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Jul 2019 16:28:25 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563312506; bh=wzucsBLUiYZjmhcXbLsOxcTTDXIJEvpyiTpJ6VLciBs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=IdhfuiQinpajBsm5EuPLmD3iwGAMySGIOFE69pxrbq72imyakSZpXQ9TO7fq4zLgJ s+O5K0vZYxX3W4ubjbZ7nFXh8i6bG9pbecbq/ZNKBaaxPq9PC7C9ggtzRBALAoO9Q8 bxm6YfGDPNiNFjFdCyUoiNGuiNsmUwbf1wwGVUKk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson , Ted Hardie Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <19180.1562875321@localhost> <26415.1563303923@localhost> From: Adam Roach Message-ID: <0e096bdf-fd85-c13f-ac4b-58ff91d9b9d4@nostrum.com> Date: Tue, 16 Jul 2019 16:28:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <26415.1563303923@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 21:28:36 -0000 On 7/16/19 2:05 PM, Michael Richardson wrote: > Ted Hardie wrote: > > Howdy, > > > I would personally not suggest using IRIs here, given that the scheme > > (https) is expected to retrieve a resource at a well-known location and > > thus will always have to be mapped to a URI to do the retrieval (rather > > than used in a string comparison or something similar) . RFC 5280, > > which this cites, actually goes through the steps pretty well, and I > > think the complexity there demonstrates the advantage for constrained > > devices of always using the URI form. > > I have changed the references from IRI to URL, and the components from > iauthority to 'authority'. > I'm happy with this solution if you are. /a From nobody Tue Jul 16 14:34:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5389120169; Tue, 16 Jul 2019 14:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 IllGZtjK0i_R; Tue, 16 Jul 2019 14:34:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9B9120139; Tue, 16 Jul 2019 14:34:11 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6GLY4ud012997 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Jul 2019 16:34:05 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563312846; bh=zI59YhqlEuLJ1jGeCL9uD3BczAvpj6CCb7KlZ7RI+Bc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=SPfDcrars3RVdGyCJxPweEW7lk0ZZ5fRel7F0DbEQoTraO6z3tt4IXTNTjfGe+GMj jyArb7KFyMDw9T/i3y6ta2H1Q9/dgRZAmEjLD51kUtevLbShYzhhItj64MUFL7coEB iogWyHD4c/ZVML/t/iJSMGSSyIevcgFP57SHTMO4= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, The IESG , anima-chairs@ietf.org References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <4679fba2-fdc9-e5ed-3474-12f4e26eca05@nostrum.com> <6413.1563299732@localhost> From: Adam Roach Message-ID: Date: Tue, 16 Jul 2019 16:33:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6413.1563299732@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 21:34:13 -0000 Michael -- Thanks so much for your work on closing this issue. Assuming the rest of the WG agrees with it, your proposed text satisfies my concern. I've indicated two minor nits below. On 7/16/19 12:55 PM, Michael Richardson wrote: > > As specified in the ANIMA charter, this work "..focuses on > professionally-managed networks." Such a network has an operator > and can do things like install, configure and operate the > Registrar function. The operator makes purchasing decisions > and is aware of what manufacturers it expects to see on it's > network. > Nit: "...on its network..." > > Such an operator is also capable of performing bootstrapping of a > device using a serial-console (craft console). The zero-touch > mechanism presented in this and the ACP document represents a Nit: add a citation for "ACP document" Thanks! /a From nobody Tue Jul 16 14:48:56 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB365120139; Tue, 16 Jul 2019 14:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cxCMj2ZMwdES; Tue, 16 Jul 2019 14:48:52 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9161200D8; Tue, 16 Jul 2019 14:48:52 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D056154800B; Tue, 16 Jul 2019 23:48:47 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BDBFD440041; Tue, 16 Jul 2019 23:48:47 +0200 (CEST) Date: Tue, 16 Jul 2019 23:48:47 +0200 From: Toerless Eckert To: Michael Richardson Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org Message-ID: <20190716214847.vyp5ce4ho6z3qkpz@faui48f.informatik.uni-erlangen.de> References: <23875.1563296300@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23875.1563296300@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] ACP SRV.est example X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 21:48:55 -0000 Thanks Added to issues on github. Waiting for an IESG review to come back to me then i can do the next rev and fix this as well. Cheers Toerless On Tue, Jul 16, 2019 at 12:58:20PM -0400, Michael Richardson wrote: > > I suggest that EST servers are never on port 80, and are likely > on port 443, or another port. > > > 6.1.4.1. GRASP objective for EST server > > ACP nodes that are EST servers MUST announce their service via GRASP > in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], > section 2.8.11 for the definition of this message type: > > Example: > > [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, > ["SRV.est", 4, 255 ], > [O_IPv6_LOCATOR, > h'fd89b714f3db0000200000064000001', > TCP, 80] > ] > > Figure 3: GRASP SRV.est example > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jul 16 15:03:26 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8E3120106; Tue, 16 Jul 2019 15:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ErKP8WT2SPRt; Tue, 16 Jul 2019 15:03:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DD41200F5; Tue, 16 Jul 2019 15:03:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D7A1054800B; Wed, 17 Jul 2019 00:03:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C5A29440041; Wed, 17 Jul 2019 00:03:07 +0200 (CEST) Date: Wed, 17 Jul 2019 00:03:07 +0200 From: Toerless Eckert To: Adam Roach Cc: Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, Michael Richardson , The IESG , Toerless Eckert , anima@ietf.org Message-ID: <20190716220307.c5ajnwyjgskyjtqk@faui48f.informatik.uni-erlangen.de> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:03:15 -0000 Adam, Not sure if you saw my reply to Alissas comments, but my biggest concern no only to fudge more and more bits and pieces into thre tailend of this draft (+1 to birans comment), but also to continue fudge them as protocol extensions into the BRSKI protocol when in reality the problems we should solve are at the architectural level, whatever protocol we use. All the things discussed here, and i think including Eliots idea would for example equally apply to RFC8572, so we would IMHO do a better job overall if from now on we would try to figue out a way to define extensions to the voucher system (or secure node behavior) in a protocol independent fashion (architecturally) first, and then just have simple adoptions to the specific protocols that want to have those extensions (BRSKI, NetConf, or whatever IoT derivations i am sure will come up). Not sure yet how to best do that, hopefully something we can discuss @105. Wrt to Eliots suggestion: Its quite interesting and maybe the only one for some slice of products, but If was thinking what really would mean "owning" to me, then thats the ability to replace the root trust anchor(s) in the device with my own. And there are cases where products at least support ADDING such trust anchors in a way that factory reset won't remove them (and only leave vendor TAs). Cheers Toerless On Mon, Jul 15, 2019 at 10:52:02AM -0500, Adam Roach wrote: > > > > On Jul 15, 2019, at 02:39, Eliot Lear wrote: > > > > To Adam???s broader point, there are at least several ways to approach this. We can leave it to the vendor to decide which is correct, and we can continue to look to standardize ideas such as the one Michael had in the message I???m replying to now. > > Yes; I think this is the important thing, and that specific mechanisms ??? if we believe they are useful to define ??? could be worked on later. > > /a > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jul 16 15:14:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432551200FA; Tue, 16 Jul 2019 15:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PFRb2fkobjJk; Tue, 16 Jul 2019 15:14:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2791512003F; Tue, 16 Jul 2019 15:14:39 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A17E3808A; Tue, 16 Jul 2019 18:14:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 26F9AB52; Tue, 16 Jul 2019 18:14:37 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:14:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have responded to DISCUSSes from: Alissa Cooper: https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm= _gPVBl5uSrU Roman Danyli: https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS= 6fENWOFRpI=20=20 Alexey Melnikov https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI= 0UtlJVZ9otY7M Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmX= RVOAV0N83yA Eric Vyncke: https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUd= EYF_iNKMvs plus comments: Mirja K=C3=BChlewind https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-= _1bf0HG46vMjf3UNaw Magnus Westlund: https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhC= mw4RDoHoN_1zE and noted comments from Barry and Warren. and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the l= ast. I'm going to use this email to deal with Ben's comments which I think we already dealt with other edits, then I'll deal with low-hanging fruit, and then decide how to deal with the desire for a high-level security analysis. Benjamin Kaduk via Datatracker wrote: > (5) RFC7951 is cited for the audit log response, but I cannot find the > underlying YANG module that is JSON-encoded using the RFC 7951 > procedures. Furthermore, I don't think the "nonce" handling (with > explicit "NULL" string where base64-encoded binary data might be > expected) would be consistent with the 7951 rules. We did not resort to a YANG data model for the auditlog responses, so I spe= nt a few minutes mystified by your complaint... then: We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159= (JSON)! (Those numbers are annoyingly similar. And we actually made this mistake before, I wonder if this was collatoral damage from a global search and rep= lace) > (6) In Section 7.2: > The pledge can choose to accept vouchers using less secure methods. > These methods enable offline and emergency (touch based) deployment u= se > cases: > 1. The pledge MUST accept nonceless vouchers. This allows for a > use > It's very unclear to me what this "MUST" means, especially so given > that the entire section 7 is declared to be non-normative. Is it that > the client "can choose" whether it "MUST accept nonceless vouchers"? > That would seem to make the MUST basically ineffective. > More broadly, if the entire Section 6 is non-normative, why is there > any normative language in it? First, I think you mean section 7? If so, the reason for normative language is because, we want to say, "if you do X, then you MUST do it this way". Second, we have referenced some pieces of section 7.2 from section 9. We think that there are significant security issues by accepting nonceless vouchers, which we discuss in 11.1. A variation of the protocol is when the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. There could otherwise be some more complex (proprietary, or documented later on) evaluation of whether to accept a nonceless voucher. For instance, the MASA could sign them with a different key, perhaps one stored in an HSM. A key point is that the Manufacturer/MASA knows exactly the rules that the Pledge has been coded to, and we don't need to agree on all these rules to get interoperability. Originally, we didn't even think we needed to standardize the voucher, just the voucher-request; but it was the desire to audit them on the Registrar that changed our mind. > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > are not registered in Section 8.1 Good catch, we have since been told by the .well-known designated expert th= at either we create a new registry, or we just ask IANA to point the "est" definition at RFC7030 and this document. Most .well-known entries do not have registries. I haven't heard a clear opinion as to which we should do. > (7.1) I think we also need to register the > "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. added. > (8) The versioning mechanism for Pledge BRSKI Status Telemetry is > underspecified, including the interaction with new registered values. This was updated based upon comments from Adam. > (9) The versioning mechainsm for the MASA audit log response is > underspecified, including whether a registry of field names is > appropriate. This was updated based upon comments from Adam. > (10) The term PKIX seems to be incorrectly used a few times; it refers > to the Internet PKI, and so things like a private PKI internal to a > manufacturer would probably not be best described as such. Such > private PKIs can of course still reuse the protocols and mechanisms > developed for PKIX, and it's accurate to describe them as such. I would never call the Internet PKI "PKIX". I'd call it WebPKI, or CAB. PKIX is the set of IETF specifications that made X509v3 useful. (And why I try never to use "X509"...) I couldn't find a reference to private PKI, so maybe I mis-understand. > (11) In a few places we describe the voucher-request in terms of its > YANG structure but do not say that it has to be wrapped in a signed C= MS > object as is done for the RFC 8366 voucher. I will review this; previous versions (prior to ~20) provided for both sign= ed and unsigned voucher requests, and we removed this feature. I added some phrases to sentences in section 3: =2D A pledge forms the "pledge voucher-request" and submits it to the =2D registrar. + A pledge forms the "pledge voucher-request", signs it with it's + IDevID and submits it to the registrar. =20 =2D The registrar in turn forms the "registrar voucher-request", and =2D submits it to the MASA. + The registrar in turn forms the "registrar voucher-request", + signs it with it's Registrar keypair and submits it to the MASA. > (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in t= he > domainID calculation? What we really want is a hash of the registrar's key/cert. We don't want to list it literally in the auditlog as it divulges too much. We just want the RFC5280 Subject Key Identifier (4.2.1.2), but since both the Registrar and the MASA need to calculate this value, we had to be specific as to how it is done. If there is a better reference with better agility, please let us know. If the Registrar could be depended upon to always provide the extension, th= en we could use the extension contents directly. > (13) In Section 5.5.1: > As described in [RFC8366] vouchers are normally short lived to avo= id > revocation issues. If the request is for a previous (expired) voucher > using the same registrar then the request for a renewed voucher SHOULD > be automatically authorized. The MASA has sufficient > I don't understand what "for a previous (expired) voucher" means. Is > it something like "containing the same content as a previous voucher > request for which a voucher was issued", with the presumption that the > voucher expired before the pledge could successfully imprint, so it > needs to try again? Or does this extend to longer timescales, like a > device that gets deployed for a couple years and is then reset to > factory settings and has to rebootstrap but is still by the same > registrar? It is intended for both uses. Either to be able to easily extend a short-lived voucher, or to get another one years later. The MASA does not need to actually use the included history; it can ignore it completely and make an entirely new decision. > (14) In Section 5.6: > The server MUST answer with a suitable 4xx > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, > the response data from the MASA MUST be a plaintext human- readable > (ASCII, English) error message containing explanatory information > describing why the request was rejected. > It seems hard to support this stance on internationalization in 2019. We don't believe that this response will go anywhere other than logs, for software suppliers to evaluate. Localizing these error message causes more problems in my experience than benefit. 90% of the information is in the 4xx/5xx code. > (15) In Section 5.9.4: > To indicate successful enrollment the client SHOULD re-negotiate t= he > EST TLS session using the newly obtained credentials. This occurs by > the client initiating a new TLS ClientHello message on the existing T= LS > connection. The client MAY simply close the old TLS session and start > a new one. The server MUST support either model. > Is this supposed to be sending a new TLS ClientHello in the applicati= on > data channel or as a new handshake message (aka "renegotiation")? The > latter is not possible in TLS 1.3 and is generally disrecommended > anyways even in TLS 1.2. I would strongly suggest to remove the > "renegotiation" option and just leave "close the connection and start= a > new connection/handshake". Okay, fixed to say: To indicate successful enrollment the client SHOULD re-negoti= ate the EST TLS session using the newly obtained credentials. This =2D occurs by the client initiating a new TLS ClientHello message = on the =2D existing TLS connection. The client MAY simply close the old T= LS =2D session and start a new one. The server MUST support either + occurs by the client closing the existing TLS connection, and + starting a new one. The server MUST support either model. > Appendix C > I don't know how important file "ietf-mud-extension@2018-02-14.yang" > is, but it seems a tad generic. I changed ietf-mud-extension to ietf-mud-brski-masaurl-extension. > Appendix D > [Just checking that Michael wants sandelman.ca embedded in the final > RFC] I don't have a problem with it. There is an error: 3726:d=3D9 hl=3D2 l=3D 55 prim: UTF8STRING :# X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92851201D0; Tue, 16 Jul 2019 15:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 2WuEvkLznzwh; Tue, 16 Jul 2019 15:36:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CEE1200E9; Tue, 16 Jul 2019 15:36:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6GMZl5T028842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 18:35:50 -0400 Date: Tue, 16 Jul 2019 17:35:47 -0500 From: Benjamin Kaduk To: Toerless Eckert Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190716223545.GB58520@kduck.mit.edu> References: <153316981032.22048.6996271018423269893.idtracker@ietfa.amsl.com> <20190311153214.c3l62vqgniuqllsf@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190311153214.c3l62vqgniuqllsf@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:36:25 -0000 Hi Toerless, On Mon, Mar 11, 2019 at 04:32:14PM +0100, Toerless Eckert wrote: > Thanks Benjamin, > > This file is: https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-ietf-anima-autonomic-control-plane/16-ben-kaduk-reply.txt > > The following inline answers to your discuss have been integrated > into -19 of the draft which i just submitted. It also includes the > feedback to the comments by Eric and Ben. I was backlogged, and > after your review of -16 i had first responded to other reviewers > with -16/-17. Thanks for the updates. I'm sorry it took so long to get feedback on them -- it took me a while to get a free day to review the whole document while I've been moving across the country and with my family's schedule. I've prepared comments on the -19 and will update my ballot position with them. I will leave unchanged the Discuss section text for a couple of points, with the understanding that we have an ongoing discussion here and that our email discussion is authoritative -- the ballot position is just to keep a note that the discussion is ongoing. > Note that this includes a hopefully more comprehensive section 6.1.3 explaining the Trust Anchor details required for the ACP, resulting from the variety of discuss of the reviewers on this topic. A welcome clarification, thanks. > Bens and Erics review where very good and comprehensive but alas > didn't make it easy for me to answer to them as quickly as i would have > wanted to. Unfortunately, i also had to go back and forth between > them, so i couldn't create a separate checkpoint version > showing ONLY changes for each of them. So the following diffs are > hopefully useful: > > -18 to -19: Changes made for Ben and Eric > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-18.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > -16 to -19: Changes since your last review (includes Alissa Coopers review) > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt > > Cheers > Toerless > > On Wed, Aug 01, 2018 at 05:30:10PM -0700, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-16: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a really exciting protocol to read about -- the prospect of > > dropping a bunch of just-manufactured devices in place, spinning up a > > registrar (and maybe a MASA), and getting a control plane like magic is > > pretty impressive. > > Thanks ;-) > > > That said, I don't believe that this document is ready > > to publish as-is. I have a list of specific points below for discussion, > > but it may be more effective to strip down the document a lot (providing a > > well-defined core protocol and leaving out speculative future work, along > > the lines of Alissa's comments) and only then start to work on specific > > rough spots. > > Thanks. I hope that the fixes to the document done in response to you > and other reviewers feedback will satisfy you. > > Let me give you some IMHO good technical arguments for the necessity of > the size of the document. there are also other charter and process arguments > but maybe better taken offline to explain. > > - You review was for -16 for -17/18, document already restructured > all speculative text into appendix A. All text in A is not unsolicited > but results of discuss/questions in the WG for this doc. > > - Section 10 (operations) is IMHO mandatory to be main text. ANIMA is an OPS > group, and overall about operational simplification, so the node-local > behavior is crucial to achieve this. Not only the interop affecting aspects > (normative sections). IMHO, this section is not speculative. > > - Stripping down the document further would create an incomplete, > and IMHO undeployable solution. The reorganization helps a lot, and there's just a couple places that I'd still consider as potential material to trim or move elsewhere. I don't think any of them rise to Discuss-level, though. > - The doc grew in the last 5..6 version by inheriting more text from what > ACP authors originally considered to be part o BRSKI document, but it turned > out to be logically better for ACP (as it's not needed in BRSKI only deployment > without ACP). In hindishgt we should have started with more documents to > split up the work (see comments on charter). IMHO too late now. > > > In particular, in its current form, it's not clear to me why this document > > is targeting the standards-track -- there are lots of places where > > determinations of what works best or how to do some things is left for > > future work. > > Futures in the normative text where only mentioned in few places IMHO. > I did another pass through the document attempting to eliminate all mentions > of futures from the normative text and most of the operational section 10. > If future is mentioned in the normative text, it is to explicitly > point out planned points of extensibility required to kepp backward compatibility. > GRASP objectives, "ext" ACP information field and the like. I think this is > standard IETF standard practice (like "reserved" fields in other protocols). > The choice of the word "future" to explain those extensibility interfaces > actually made it easy to find them in the text... > > So, IMHO, all the functionality written into the normative parts as of -19 > are really mandatory to support the best understood deployment scenarios well. > > > Are there lots of implementations or consumers clamoring for > > this stuff that it makes sense to go for PS as opposed to Experimental (so > > as to figure out what works and nail down a slimmer protocol for the > > standards track)? > > I definitely have worked with a quite a few number of customers > interested in this technology and using pre-standards versions of it, > asking for it to be standardized. As mentioned before, i also don't > think there are optoinal pieces in the normative part that are experimental > and not well enough understood from implementation/deployment experience. I also see the shepherd writeup has been updated to include some implementation notes, which is helpful/reassuring, too. > This is really mostly a a way to stitch together well known techniques and > protocols (secure connections, separate VRF across a network, certificate > management) and easily automated IPv6 addressing schemes. Add a fairly > small standard track target negotion protocol (GRASP). > > Alas, there is a good amount of complexity in stitching these pieces together > so everything becomes self-configuring and secure. I think I can imagine! (But I probably actually can't, and am missing some pieces.) > > I see in A.4 that the choice of RPL was motivated by > > experience with a pre-standard version of ACP; it would have been great to > > hear more about those deployments in an Implementation Status section (per > > RFC 7942) or the Shepherd writeup. > > Yes. There is a lot of experience gained from pre-standard vendor production code > running in customer networks, only modified/enhanced in places > where the authors of the ACP draft and/or the WG felt that that > pre-standard implementation does not meet standards track expectations. > There is also open source code experience through an Open Daylight project > nd other ongoing open source linux work. > > When i as the shepherd for BRSKI asked the authors for a section of implementation > experience, they punted it back to me and it ended up in the shepherd writeup. > Given how you where concerned about the document size as well, i would therefore > rather go with the shepherd writeup approach for ACP as well. The main > difference is the use of GRASP in the standards version versus a vendor > specific protocol for signaling and service discovery of the ACP. > > You can get a good detail overview of the functionality of the commercial implementation > by looking up BRKSDN-2047 on cisco.com (requires to register an account) > or less detailled info googling "Cisco IOS Autonomic Networking" documentation. > > > I also think the document needs to be more clear about what security > > properties it does or does not intend to provide: we hear in the abstract > > and introduction that ACP will be "secure" (and similar platitudes are > > repeated throughout) > > Agreed, there should not be platitudes. But i am not sure that a global > substitute of "secure" with "public key certificate authenticated and encrypted" > would make the document any more readable, so i welcome explicit suggestions > where specifically you think the text has platitudes and i will do my > best to eliminate them. Note also that the introduction section is > somewhat vague beause its pretty much the "requirement specification" for > the ACP and it reflects really what operators would express. The normative > section is then filling those vague requirements with working specification > (Charter/ADs did not want us to write separate requirements documents). > > > but we don't really get a sense of the specifics > > until Section 4, with ACP5. This has a MUST for authenticated and "SHOULD > > (very strong SHOULD)" be encrypted. > > This is one of those non-normative places where requirements are described. > This already went through some changes since -16 and now has only lower > case should/must so it can't be confused as rfc2119 and introductory text > to clearly explain how it describes requirements against the normative part > of the doc and how the normative part meets and exceeds these requirments. > > > But text elsewhere in the document > > seems to be using "secure" to also mean encrypted, and there is even one > > place that flatly asserts that "ACP mandates the use of encryption". This > > internal inconsistency needs to be resolved, at a minimum, and ideally the > > intended posture more clearly conveyed. (It's also not really stated under > > what cases encryption would not be used, so that the "very strong SHOULD" > > could not be a MUST.) > > Check if you think there is still an inconsistency. Section 4. is requirements > which are "strong should". The normative section has MUST against implementations > of this specification as a response. So, this should vbe perfectly alignet. This aspect does look a lot better in the -19; thank you. > The normative MUST of the spec is what we know the IETF security review > expects the solution to provide (and what the authors believe to be required > too btw). The "strong should" of the section 4 requirements reflects on the > fact that many operators do actually not care about the security as much as > we would like them to because they believe to operate in physically secure > enough environments (datacententers or the like). > > > Section 3.2 claims that the ACP provides "additional security" for > > bootstrap mechanisms due to the hop-by-hop encryption. But in what sense > > is actual additional security gained? Against an attacker with what > > capabilities? If there is security gain from such hop-by-hop encryption, > > doesn't that point to a weakness in the bootstrap scheme? > > Replaced with: > > > The ACP also provides additional security for any bootstrap mechanism, because it can provide encrypted discovery (via ACP GRASP) of registrars or other bootstrap servers by bootstrap proxies connecting to nodes that are to be bootstrapped and the ACP encryption hides the identities of the communicating entities (pledge and registrar), making it more difficult to learn which network node might be attackable. The ACP domain certificate can also be used to end-to-end encrypt the bootstrap communication between such proxies and server. Note that bootstrapping here includes not only the first step that can be provided by BRSKI (secure keys), but also later stages where configuration is bootstrapped. > > Aka: You can't observe by observing network traffic who is talkking to whom to "spot the pledge" or "spot the registrar" Thanks! > > I think there needs to be some justification of why rfc822Name is chosen > > over a more conventional structure in the otherName portion of the > > subjectAltName, which is explicitly designed to be extensible. > > There is a comprehensive reasoning for the choice of rfc822Name in 6.1.1 > that had us conclude this is the safest bet of the options we understand. > > Also added: > > The element should not require additional ASN.1 en/decoding, because it is unclear if all, especially embedded devices certificate libraries would support extensible ASN.1 functionality. > > For otherName, i am worried about something like this: > > > Currently OpenSSL doesn't display any otherName values. It can't know the precise meaning of that field in general because the format could be totally arbitrary. At best it could asn1parse the contents. > > Aka: We wanted to use a field where we know every implementation supports > but that is also not conflicting with other pre-existing uses. > We did not want to rely on additional ASN.1 parsing of its content, because > embedded implementations might have fixed parsers. Thats why we choose a > a simple non-ASN.1 encoding of a field we know is always supported but > never used for actual network functionality so it can not conflict. And > if anything else uses already this field, you would actually see emails > to an address because the format we choose is a working rfc822name I still feel like this is not the best architectural choice. Later on you ask for some guidance on what the ASN.1 structure for an otherName solution would/could look like; I'll include that in my updated ballot position's Comment section. > > The requirement in Section 6.1.2 for CRL and OCSP checks seem impossible to > > satisfy for a greenfield node without non-ACP connectivity, as it must join > > the ACP domain (and supposedly validate the CRL and OCSP validity before > > doing so) before establishing an ACP link with its peer, but cannot > > validate anything with no connectivity. > > ACP is not concerned with greenfield nodes, thats BRSKIs job or any other > solution that provision the certificates. So the ACP node will already > have a working cert. But there is definitely the issue that an ACP node > may not have access to current CRL or OCSP responder. > > I added the following to the end of that text: > > | This rule has to be skipped for ACP secure channel peer authentication > | when the node has no ACP or non-ACP connectivity to a CDP or OCSP responder > | and only expired CRL information. > > This still leaves the quagmire problem that a node connects to only > one other ACP node, then it retrieves a CRL through the ACP connection > across that node, and then it learns that that peer nodes certificate > was revoked. There is a new paragraph outlining that too (close ACP > connection, retry periodically. peer could be happy and receive a new cert.). Thanks; the general premise here seems reasonable. > > Throughout, the document seems to implicitly conflate authentication with > > authorization. I understand that the main authorization check is just the > > domain membership test in Section 6.1.2; nonetheless, as a pedagogical > > matter I cannot support propagating their conflation. > > There are about 37 places in the document where the word authentication > is used to refer to something which is probably formally correctly > authentication and authorization. This formal precision was not asked > before in any other review, and i think also it would make the document > less readible if i went through all places and replaced authentication > with authentication and authorization. Primarily because in my understanding > that this conflation is pretty common practice for brevity when there really > is no configurable authorization policy but when that logic is what i would > call hard-coded - as i think it is in the case of the ACP (or rather this spec, > i could see that followup work might want to introduce actually configurable > authorization policies via intent). > > For example i have not seen any text about web browsers > that said that the authentication of the web browsers certificate > authorizes the browser to display some cool looking icon and skip > bothering the user with all type of warnings. Even though i hope this > would be an appropriate use of the word authorization. > > So. could i negotiate you down to the following one paragraph added to the > end of 6.1.2: > > Formally, the ACP domain membership check includes both the authentication of the peers certificate (steps 1...4) and a check authorizing this node and the peer to establish an ACP connection and/or any other secure connection across ACP or data plane end to end. Step 5 authorizes to build any non-ACP secure connection between members of the same ACP domain, step 5 and 6 are required to build an ACP secure channe. For brevity, the remainder of this document refers to this process only as authentication and instead of as authentication and authorization. I have a wording quibble (in new-ballot Comment) but the general premise is sound. > If not then i would welcome expllicit text proposal or at least a strategy > what to do about those 37 text places. > > > In a few places, the MTI cryptographic mechanisms are under-specified, > > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > > to note these locations in my section-by-section comments. > > Thanks. See below. Should also have been fixed through Erics review. There seem to be a tweak or two left (though to be honest I will need to consult someone more knowledgable in IKEv2 than me). > > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > > root, but if I understand correctly the RPL root is automatically > > determined within the ACP, and thus the operator does not a priori know > > which node will become the RPL root. Am I misunderstanding, or is this > > effectively placing this requirement on all ACP nodes? > > More or less, yes. Packet counter on the default route to a null interface for example, > maybe a HW register for the last thus discarded packets destination address, > allowing at least sampling of such addresses. Thats what i was thinking > of suggesting if i ever manage to move on from this spec to the YANG model for > the ACP. > > I am sure we could reduce requirements by differentiating between nodes > that should never become root, but that would lead to even more text > lamenting about ad-hoc type of ACP setups. Besides, its a SHOULD and even > low-end IoT devices using CPU forwarding would have no issue implementing this. I agree with the assessment of low likelihood of actual problems, but would appreciate a brief note in the text. > > The IANA considerations specifically do register SRV.est in the GRASP > > Objective Names Table, and then follows up with a paragraph that this is > > only a "proposed update". I don't know if there's actually anything > > problematic here, but the document does need clarity on what is proposed > > for future work and what is to be done now. > > Ok, how about this changed paragraph. Hopefully its explaining it better. > If not, then please ask what you do not understand and once you understand, > please suggest text: > > t>Explanation: This document chooses the initially strange looking format "SRV.<service-name>" because these objective names would be in line with potential future simplification of the GRASP objective registry. Today, every name in the GRASP objective registry needs to be explicitly allocated with IANA. In the future, this type of objective names could considered to be automatically registered in that registry for the same service for which <service-name> is registered according to . This explanation is solely informational and has no impact on the requested registration. This (or rather, what's in the -19, which is probably the same) helps a lot. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some high-level comments that do not quite meet DISCUSS criteria appear > > below, followed by section-by-section inline comments. My apologies for > > not splitting them between substantive and editorial, but I don't think I > > have enough time left before the telechat to do that and finish the other > > reviews I have remaining. > > Sure. No worries. > > > The whole premise of the ACP is for it to be almost entirely autonomic and not > > require external configuration. But some pieces/functionality do require > > explicit configuration (e.g., manual ACP addresses, configured remote ACP > > neighbors, etc.), so I would have liked to see a section discussing what > > sort of interface might be used to inject manual configuration into the > > otherwise autonomic system. Would this be done using ACP control messages > > from an NMS using an ACP connect node, or an out-of-band (serial) > > management port, or something else? > > Ok, added at the end of the operations chapter 10 a new section 10.4. > "Configuration and the ACP (summary)" > > This is all restatements i think of what should already have transpired via > various parts of the document, but i can easy see how one would want to > search in the document for something like ACP and configuation. > > Let me know what you think. If not sufficient, please ask if you don't > understand something, else pls. propose text. I think it's a big help! If I were going to change anything, I might add a note about how preexisting NMSes will need ACP-connect until such time as there is a single device that is ACP-native and also exposes a non-ACP admin interface to any relevant ACP functionality. But that assumes that I understand the current and desired future state of affairs, which I am not fully confident is correct. > > I think the document needs to be more clear about its stance towards > > constrained nodes: DTLS is supported (along with IKEv2+IPSEC), supposedly > > for the benefit of constrained nodes, but then the more heavyweight TLS is > > required for several operations within the ACP itself. > > Right. > > I added to applicability section 1.1: > > | Support for constrained devices in this specification is opportunistic, but not complete, because the reliable transport for GRASP (see only specifies TCP/TLS). > > The text afterwards already points to A.9 where i modified the main > missing steps to get rid of TLS/TCP with future work: > > | Hop-by-hop reliability for ACP GRASP messages could be made > | to support protocols like DTLS by adding the same type of > | negotiation as defined in this document for ACP secure channel protocol negotiation. > | End-to-end GRASP connections can be made to select their transport protocol > | in future extensions of the ACP meant to better support constrained devices by > | indicating the supported transport protocols (e.g.: TLS/DTLS) via GRASP parameters > | of the GRASP objective through which the transport endpoint is discovered.< > > Opportunistic means that it was important for us to have a second useful > secure channel protocol beside IPsec to be able to have an actual case for a > secure channel selection mechanism and the fact that we do not need > a network wide MTI protocol for that because secure channels are hop-by-hop only. > Any further work for DTLS-only nodes would IMHO better be suited to a future > constrained ACP profile document. Okay. > > Section 1 > > > > of the ACP (after all the details have been defined), Section 10 > > provides operational recommendations, Appendix A provides additional > > explanations and describes additional details or future work > > possibilities that where considered not to be appropriate for > > > > nit: s/where/were/ > > fixed pre 19. > > > [...] The ACP can > > be implemented and operated without any other components of autonomic > > networks, except for the GRASP protocol which it leverages. > > > > This could probably benefit from being disambiguated between the single > > ACP-wide GRASP instance and the DULL GRASP used for link-local > > flooding/discovery. > > Added: > > ACP relies on per-link DULL GRASP (see ) to autodiscover ACP neighbors, and includes the ACP GRASP instance to provide service discovery for clients of the ACP (see ) including for its own maintenance of ACP certificates Thanks! > > Section 1.1 > > > > [...] The ACP can operate equally on > > layer 3 equipment and on layer 2 equipment such a bridges (see > > Section 7). The encryption mechanism used by the ACP is defined to > > > > nit: such as > > thanks > > > be negotiable, therefore it can be extended to environments with > > different encryption protocol preferences. The minimum > > implementation requirements in this document attempt to achieve > > maximum interoperability by requiring support for few options: IPsec, > > DTLS - depending on type of device. > > > > nit: This last sentence could be reworded for clarity, "[...] requiring > > support for multiple options (IPsec and DTLS), depending on the type of > > device." > > Thanks. > Had to spell out DTLS as this was introducing the term, so slightly different: > > The minimum implementation requirements in this document attempt to achieve maximum interoperability by requiring support for multiple options depending on the type of device: IPsec, see , and datagram Transport Layer Security version 1.2 (DTLS), see ). > > > Section 2 > > > > ACP address: An IPv6 address assigned to the ACP node. It is stored > > in the domain information field of the ->"ACP domain certificate" > > (). > > > > nit: The "->" and "()" seem like artifacts from an editor also usable for > > source code? ("->" also appears in "ACP domain"'s definition, and both > > appear in the "in band (managemnet) definition and the "(virtual) > > out-of-band network" definition.) > > There is a longer rant to the RFC-editor about this since -17 in the text [RFC-editor:...]. > xrefs to hanging style word definitions et.al. Will fix when doc gets > to RFC editor. They may have simpler means to do this than the limited XML > we have. > > > EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard > > protocol for enrollment of a node with an LDevID. BRSKI is based > > on EST. > > > > RFC 7030 is only Proposed Standard, so "standards-track protocol" > > seems more appropriate. > > thanks. > > > (virtual) out-of-band network: An out-of-band network is a secondary > > network used to manage a primary network. The equipment of the > > primary network is connected to the out-of-band network via > > dedicated management ports on the primary network equipment. > > Serial (console) management ports where historically most common, > > > > nit: s/where/were/ > > fixed pre-19. > > > Please use the actual RFC 8174 instead of attempting to reproduce (but not > > exactly) its updated boilerplate. > > fixed pre-19. > > > Section 4 > > > > ACP4: The ACP MUST be generic. Usable by all the functions and > > protocols of the ANI. Clients of the ACP MUST NOT be tied to > > a particular application or transport protocol. > > > > nit: The second sentence is only a sentence fragment. > > fixed pre-19: > The ACP _MUST_ be generic, that is it MUST be usable by all the functions and protocols of the ANI. > > > ACP5: The ACP MUST provide security: Messages coming through the ACP > > MUST be authenticated to be from a trusted node, and SHOULD > > (very strong SHOULD) be encrypted. > > > > authenticated as coming from a trusted node, or authenticated to be > > from a specific node, which is known to be trusted? > > Hah. The requirement was defined in the beginning of the WG to be as > written and it was not more specific. We worked the solution off of it. > We choose to use hop-by hop authentication/encryption because it > provides better infrastructure protection, but this does not mean that > an end-to-end authentication/encryption would not also be a possible > solution against the requirement either, so i would like to not be more > specific here - because i am thinking of proposing that alternative in > future work: The op-by-hop encryption provides best infrastructure > security, but as already mentioned, hardware may have problems, so > we could have future work defining ACP variations with just end-to-end > encryption (more limited in infrastructure and perpass protection). > > Aka: no change done now. Thanks for the background. Given the status of this requirements section, it seems reasonable to leave as-is. > > Also, maybe "MUST, except for [...]" is better than "very strong > > SHOULD". (What are the execptional cases where plaintext is allowed?) > > Integrity protection of authenticated traffic may be worth mentioning > > explicitly. > > Hope its clear from my prior explanation that this section describes the > operator requirements input into the development of the ACP solution and > not the output (deleted charter limitation rant). > > > > Th eACP operates hop-by-hop, because this interaction can be built on > > > > nit: s/Th eACP/The ACP/ > > thanks > > > Section 5 > > > > 3. For each node in the candidate peer list, it authenticates that > > node and negotiates a mutually acceptable channel type. > > > > There seems to be an implicit step in here, "confirms that the node is > > authorized to be a part of the same ACP domain". Presumably this is usally > > the "ACP domain membership check" of Section 6.1.2; a forward reference > > seems in order. > > ack. > > > Section 6.1.1 > > > > It's slightly jarring to use ABNF to specify the contents of an > > ASN.1 field. > > See earlier discuss in this mail and text added text to justify it. > > (admittedly i am also a fan of the good old human readable > "Simple Something Protocol" approach of the IETF of distant times, > so please also take my age into consideration ;-) > > > hex-dig is case-insensitive; is that intended? > > Hmm. Not, its specified in the following line as case sensitive: > > hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" > > DIGIT was predefined ABNF, couldn't find any hex, didn't find a > reason why case insensitivity would be a lot of help here... If I'm reading https://tools.ietf.org/html/rfc5234#section-2.3 properly you have to go for %d97 etc. to get case-sensitivity; RFC 7405 adds the %s extension that is more readable. > > "acp-address" seems under-specified and maybe over-constrained, in > > that it does not say how to get what digits to put there, and in > > that limiting to 32 hex digits may prevent the use of alternative > > ACP address schemes in the future, as is suggested as a possibility > > in the body text. > > You do not need to create a new encoding if you pick an unused > type field in the ACP address. COming up with new encodings > in the ACP domain information field is orthogonal: > > rfcSELF.0++XXYABC1234567@new-acp-domain.com [1] > rfcNEXTwhaeverelse@new-acp-domain.com > > Those are the two extensibility options we already have: > [1] is backward compatible with this ACP spec and the > strange string is some form of indicating an address. Existing > nodes would think that nodes does not have an ACP address (0). > [2] would just change the key field and be able to copy everything > it likes about the current format, and change everything it doesnt like. > > What type of ABNF improvement would you propose to make > extensiblity even better ? Reading this again, I was probably confused when I wrote the original comment; given how tightly the ACP is integrated with IPv6 I don't see a need for any change here in this regard. > > [...] If the operator does not own any FQDN, it should > > choose a string (in FQDN format) that intends to be equally unique > > > > I don't know if it's worth cautioning against making up fake > > TLD-equivalents, given how this has bitten people as new TLDs come > > online. > > I'll be happy to add a reference if theres any good text to point to, > but would not want to dare wasting space on suggestions how to best not > get caught with something that can always be a problem. > > The acp-domain name only becomes security relevant within > a single PKI root, otherwise it is just human diagnostics, so the problem is > IMHO not big. As long as you don't name your ACP domain > "acp.example.com" or whatever domain names are mentioned as examples > in documentation. I think there is even some text about this in the Appendix :) > > I'm not sure that "people implementing our stuff have an easier > > time" is a great reason to stuff randomly-shaped stuff into an > > existing hole, especially when there's this nice otherName-shaped > > hole available right next to it. > > If you want to propose text for the ASN.1 encoding of ACP domain > information, we could let the WG decide. So far the WG did agree > on the rfc822 option, and i wouldn't even know how to define the > ASN.1 in a way i would feel safe to not have overlooked any possible > issue - any ASN.1 expert around with free time ? > > As said: If it was me, i would still prefer to not use ASN.1 for the > internal encoding due to risk of non-extensibility of existing low-end > parsers and more limited diagnostic to humans. As mentioned above, I put some more thoughts on this in my new ballot position. We should probably fork off a new subthread for the rfc822Name vs. otherName question. > > o The format of the rfc822Name is chosen so that an operator can set > > up a mailbox called rfcSELF@ that would receive emails > > sent towards the rfc822Name of any node inside a domain. This is > > possible because in many modern mail systems, components behind a > > "+" character are considered part of a single mailbox. In other > > words, it is not necessary to set up a separate mailbox for every > > ACP node, but only one for the whole domain. > > > > This is effectively codifying that foo+bar@baz === foo@baz in email > > addresses, which perhaps merits some broader discussion (especially in the > > context of security issues when different providers disagree about whether > > local components of email addresses differing after a '+' are the same or > > not!). > > We had a pretty broad discussion asking folks if they where aware of > email addresses in certificates of network devices ever being used > for something automatically (aka: not through visual inspection by a human), > and nobody had an example. Thats why we felt it was quite safe to choose > the rfc822 format. The use of "+" then was just opportunistically using > what might be the best use of existing practices, but without expecation > that this would actually be ever used. We do occasionally publish documents that change the semantics or expectations around existing fields after such analyses, but AFAIK we always include the justification and summary of research in the document doing so, along with calling out that there is a change. > > Section 6.1.2 > > > > o The peer's certificate is signed by one of the trust anchors > > associated with the ACP domain certificate. > > > > This seems to preclude having a PKI structure that is common in the web > > world, of a highly secure, offline trust anchor that only certifies > > intermediate CA certificates, with the intermediates certifying end-entity > > certificates. Perhaps the intention is that the peer's certificate chains > > to such a trust anchor? > > Indeed, thats what we want. > > Fixed already for Erics review: > > 3: The peer's certificate passes certificate path validation as > defined in [RFC5280] against the Trust Anchor associated with the > ACP nodes ACP domain certificate (see Section 6.1.3 below). > > Hopefully this is correct text. If there is a better way to say it, proposed > text would be higly welcome. > > > o The peers certificate has a syntactically valid domain information > > field (subjectAltName / rfc822Name) and the domain name in that > > peers domain information field is the same as in this ACP node > > certificate. > > > > Is this supposed to be an exact byte-for-byte match, or is some form of > > insensivity allowed that would require normalization/canonicalization prior > > to comparison? > > Added "(lowercase normalized)" to the comparison requirement for the acp-domain-name. Does this imply A-labels (RFC 5890)? > > Section 6.1.3 > > > > I had noted (in my local notes) on the -13 that using the ACP address and > > only storing one EST server makes for a single point of failure; the > > situation seems somewhat improved in the -16 in that the remebmered value > > is used as the first attempt for renewal, but presumably with GRASP > > announcement as a fallback there is less of a single point of failure. > > Yes. that seemed like a good compromise. Stickyness to prior registar > is meant to ease diagnostics in hopefully many cases and maybe speed up > the process. > > > Section 6.1.3.1 > > > > Does the example need a comma after 255 to indicate the absent > > objective-value? > > I don't think so in my interpretation of CDDL. We had a couple of reviews > from folks who should know CDDL better, nobody brought this up. Hope > they are reading this mail. > > > (Also, putting the example after the CDDL might help the > > reader know what they're looking at.) > > If i get another voice for that order i'll change it (you are the first one to > voice this preference). Personally (as what probably is lazy reading, i always > like it better to see an example first, before being dragged into a > full specification/format-explanation. Most likely i only want to read > up some details from the spec because i can already guess most of it from > the example. > > > The "formal CDDL definition" of flood-message seems somewhat > > informal at times, e.g,. for loop-count. > > Its not meant to be informal. > Any other place in the definition where you think it is too informal ? > > The strong choice of 255 for TTL is based on not knowing how large > the network is and no means defined to figure out automatically how large it is. > When we get to defining a YANG model, i'd make it a parameter if being forced > to, but from a decade of experience with TTL scoping in IP multicast > i certainly would like to avoid it. > > Let me know if you think any of scuh explanation needs to be added to the > text or what else you don't like. It looks like I wanted a few things changed/clarified: - the hardcoded loop-count of 255 with comment "recommended" seems jarring; "automated detection not possible" or something similar to what you write above might be more helpful - "Not used (yet)" is also a bit informal; "reserved for future extensions" might be more typical - I wasn't sure if we needed to call out 'initiator' and 'ttl' specifically as being used unchanged from another ref (assuming that ttl and loop-count are different). > > Using both "[t]he objective value" and an "objective-value" field for > > different things is needlessly confusing; can the body text be clarified > > somewhat about the value "SRV.est"? > > That was a bug on my behalf. SRV.est is called the objective name in GRASP. > Fixed. > > > Can "negligbile traffic" be quantified? > > No. Its in the eye of the beholder (network admin). 30...60 seconds is used > in all typical protocols i remember and will be fine for all non-low bitrate > networks. Once you get into lower bitrates (below 1 Mbps ?) i would expect > operators may find 30...60 seconds not negligible. I see this question is still coming up in the BRSKI balloting, but I don't think I myself have more to say on the subject. > Aka: this would have to be configurable until we have enough experience > to define an automatic distributed backpressure mechanism like in RTCP RRs > multicast reports (this is not a question of the SRV.est reports alone > but the sum of all flooded service reports IMHO). > > > Section 6.1.3.3 > > > > [...] If the CDP URL uses an IPv6 address (ULA address when using > > the addressing rules specified in this document), the ACP node will > > connect to the CDP via the ACP. > > > > Seems to be duplicated? > > vi fumble. thanks. > > > HTTPs connections. The connecting ACP node SHOULD verify that the > > CDP certificate used during the HTTPs connection has the same ACP > > address as indicated in the CDP URL of the nodes ACP domain > > certificate > > > > Presumably only if the CDP URL listed an IPv6 address. > > (Also, nit: full stop at end of sentence.) > > added: if the CDP URL uses an IPv6 address.o > fixed nit. > > > Section 6.1.3.4 > > > > A reference to draft-ietf-acme-star and/or draft-nir-saag-star might be > > useful to inform the reader of related work. (Note that the latter was not > > adopted by the LAMPS WG yet, with the indication that some changes were > > needed before it would be appropriate for adoption.) > > Thanks. Added a "see also draft-ietf-acme-star". > > > Section 6.2 > > > > [...] An ACP node MUST > > maintain this adjacency table up to date. > > > > Up to date on what timescale? > > Removed "up to date". Does this resolve your comment ? Yes > > The adjacency table MAY contain information about the validity and > > trust of the adjacent ACP node's certificate. However, subsequent > > steps MUST always start with authenticating the peer. > > > > Also verifying that it is authorized for the operation in question? > > Replaced "start with..." by > "start with the ACP domain membership check against the peer (see )" > > > Section 6.3 > > > > The result of the discovery is the IPv6 link-local address of the > > neighbor as well as its supported secure channel protocols (and non- > > standard port they are running on). It is stored in the ACP > > Adjacency Table, see Section 6.2 which then drives the further > > building of the ACP to that neighbor. > > > > nit: "see section 6.2" is probably better in parentheses, but if commas > > are used, they need to be both before and after it. > > Fixed. > > > Section 6.4 > > > > o Build the ACP across all domains that have a common parent domain. > > For example ACP nodes with domain "example.com", nodes of > > "example.com", "access.example.com", "core.example.com" and > > "city.core.example.com" could all establish one single ACP. > > > > If this wasn't an example it sounds like it'd need to reference the > > public suffix list? > > Please check out the text as it was changed from other -16 review, > the whole intent section (because is futures) is now appendix A.8. > > Aka: this is more about mutual agreement of two domains to trust each other > and coming up with appropriate means to share trust anchor (aka: not easy). I'm still kind of unclear about Intent and how baked it is (see new ballot text) ... > If you don't mind elaborate about public list, i am interested if > that would be a simpler solution. ... but the public suffix list is a hack in the web community to avoid over-coalescing for things like cookie storage: https://publicsuffix.org/ I don't think anyone's particularly happy that it exists, but the alternatives we know about (including not having it) are worse. > > Section 6.5 > > > > o An ACP node may choose to attempt initiate the different feasible > > > > nit: to attempt to initiate > > Done. > > > Section 6.6 > > > > "Exponential backoff" requires the base of the exponent to be specified in > > order to be well-defined. (An base of, e.g., 1.0000001 is hardly any > > backoff at all, over our normal timescales.) > > There is no unspoken verbal default of 2 ? There probably is, but I have this warped history involving a degree in mathematics... > Which scheme doesn't use 2 ? ;-)) > > Fixed to: > > "...default is exponential base 2 backoff with a minimum..." > > > Section 6.7.1.1 > > > > [...] It MUST then > > support ESP with AES256 for encryption and SHA256 hash and MUST NOT > > permit weaker crypto options. > > > > That does not fully specify cryptographic parameters for > > communication security, e.g., CTR vs. CBC vs. GCM mode of AES. > > (Similarly in Section 6.7.1.2.) > > Same comment from Eric. Proposed text: > > It MUST then support ESP with AES-256-GCM () for encryption and SHA256 hash and MUST NOT permit weaker crypto options. Key establishment MUST support ECDHE with P-256. > > I have only been able to vet a little bit, but i hope we're on solid > ground not limiting the amount of current HW crypto by the choice of GCM > but rather even improve HW acceleration support by choosing it as the MTI. > > Let me know if there are any other forgotten parameters. Sugggestest > MTI choice highly welcome. Guidance is simply the currently likely > most widely HW accelerated supported option meeting common security > level expectations (yes i know thats hard to quantify). I think we should probably check with an IKEv2 expert. In general I'd expect referring to specific codepoints from https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml to be more reliable than just textual descriptions. > > In terms of IKEv2, this means the initiator will offer to support > > IPsec tunnel mode with next protocol equal 41 (IPv6). > > > > nit: "equal to" > > fixed. > > > ESP is used because ACP mandates the use of encryption for ACP secure > > channels. > > > > I thought this was only a "very strong SHOULD", not mandatory. > > (Similarly in Section 6.7.1.2.) > > Should be clear by now. We changed from SHOULD to MUST a couple of > versions ago, because the only way to avoid downgrade attacks if we > permit unencrypted is to come up with some domain certificate extension > allowing null-crypto, and if there are really enough markets > (data center etc.) wanting this, its easily done in a followup > document. Sounds good. > > Section 6.7.1.2 > > > > (Lots of this section duplicates 6.7.1.1 and could be consolidated into > > the toplevel 6.7.1.) > > really just the one paragraph specifying the crypto parameters, > all the other text in the two sections is different. Given how > confusing all these IPsec options can be (transport vs. tunnel for example), > i felt it was easier to keep the options clearly apart to avoid falling > victim to readers/reviewers assuming some parameters could be same when its not. Okay. > > If IKEv2 initiator and responder support GRE, it will be selected. > > The version of GRE to be used must the according to [RFC7676]. > > > > nit: the grammar in the last sentence is weird; maybe "must be determined > > according to"? > > Thanks. Done. > > > Section 6.7.2 > > > > To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP > > port is used that is announced as a parameter in the GRASP AN_ACP > > objective to candidate neighbors. All ACP nodes supporting DTLS as a > > secure channel protocol MUST support AES256 encryption and MUST NOT > > permit weaker crypto options. > > > > You should specify actual ciphersuite, signature, and hash > > algorithms. > > Trying to outsource to prior work (rfc7525) after discuss with eric earlier. > Text is now: > > All ACP nodes supporting DTLS as a secure channel protocol MUST > adhere to the DTLS implementation recommendations and security considerations of except with respect to the DTLS version. ACP nodes supporting DTLS MUST implement only DTLS 1.2 or later. For example, implementing DTLS-1.3 () is also an option. I think there was still somewhere that talked about TLS encryption/ciphers specifically (and not as ciphersuite codepoints). Especially if you reference it as BCP195, omitting any specific ciphersuite/etc. values from this document is fine. > > Section 6.7.3 > > > > I would recommend calling out the "terminate channel when certificate > > expires" behavior again in the security considerations, as it would be > > surpirsing to readers expecting the "standard" behavior. > > Added to security section: > > Because ACP secure channels can be long lived, but certificates used may be short lived, secure channels, for example built via IPsec, need to be terminated when peer certificates expire. See . Thanks! > > nodes with an area of baseline ACP nodes MUST therefore support IPsec > > and DTLS and supports threefore the baseline and constrained profile. > > > > nit: s/threefore/therefore/ > > Previously fixed. > > > Section 6.8.2 > > > > The figure does not really aid my understanding absent some > > additional explanation. > > Hmm. hard to understand what specific explanations you would require. > There already is a lot of explanation. Can you maybe ask specific > questions that would help me write the fitting explanations ? [see new ballot text] > > GRASP unicast messages inside the ACP always use the ACP address. > > Link-local ACP addresses must not be used inside objectives. GRASP > > > > Link-local *ACP* addresses, or IPv6 ones? > > Changed to "Link-local addresses from the ACP VRF". > > We did phrase the term "ACP address" to only refer to the certificate > provided ULA IPv6 address (assigned on loopbacks) to make the > terminology easy for operators/users. The don't even need to think > any more about the VRF. The implementer on the other hand will know > about the VRF, and for them the term "ACP address" may be referring > to any address of the ACP VRF. So we need to be careful in > terminology here. So i think calling out ACP VRF explicitly does that. > > > [...] GRASP > > unicast messages inside the ACP are transported via TLS 1.2 > > ([RFC5246]) connections with AES256 encryption and SHA256. > > > > Same comment as before about ciphersuite/etc. > > Hmm. I think Eric missed this one ;-) > > TBD: Could you recommend a good equivalent to rfc7525 to refer to for a > good TLS 1.2 profile that i could refer to I think I'm confused; why is 7525 itself not usable? > > Also, TLS or DTLS (noting > > that constrained devices are assumed to only implement DTLS)? > > Yes, see note abbout "opportunistic" but not complete support for > constrained devices in the applicability section 1.1 that i mentioned. > The spec is not sufficient for constrained device, it only specifies > those aspects we understand and wanted to include. > > Right now IMHO we have not enough participants experts for constrained > devices in the effort to really be sure that we have a sufficient solution > for specific type of constrained devices. > > One problem are the end-to-end connections. We need for example > EST via DTLS, or rather via CoAP ? ACME ? for cert renewal, and once > we're happy with that, we can figure out if we'd get away with the same > type of mods for GRASP unicast connections. DTLS has some strage partial > reliability if i remember correctly, so we may need application level > transaction retries, and i don't think that GRASP has gone through that > analysis either. > > > Also, TLS 1.3 is in the RFC Editor's queue; is there work underway > > to adapt to it? > > No plan right now. Router software is so slow to update so we'd easily > create big implementation hurdles short term. > > Given how TLS for GRASP is only defense against attacks from inside the > ACP (secure channel IPsec/DTLS protect against attacks from outside). > > I am actually also not a fan of the certificate hiding of TLS 1.3 for > the use-case inside the ACP. If i have traffic going across the > internet i definitely want TLS 1.3 against perpass, but if i am > a single domain network operator running an IPsec hop-by-hop encrypted > management network inside of which there is TLS between my network > devices, then tracing of domain certificates may be my last easy > report for diagnostics and troubleshooting. > > > [...] TLS and TLS connections for GRASP in the ACP use the IANA assigned > > TCP port for GRASP (7107). > > > > Is one of those supposed to be DTLS? Is the IANA-assigned port > > assigned for both TCP and UDP? > > Fixed to TCP and TLS - we only use TLS for end-to-end inside ACP, > for single-hop we use TCP because there is nothing gained by TLS > over the underlying single-hop IPsec/DTLS encryption. > > Yes, port is assigned for TCP and UDP by GRASP but not mentioned > here because - see above discussion - there is more to resolve than > just saying "use DTLS" to make embedded devices completely happy. > > > Section 6.8.2.1 > > > > As a side note, I don't mind seeing discussion about potential future work > > to avoid the double authentication/encryption, but my intuition is that > > it's not really worth pursuing. > > Yes, i primarily wrote this to ensure the insight isn't lost. > The encryption hardware is struggling with is the hop-by-hop one because > it needs to scale with the amount of transit traffic. authentication > is IMHO not an issue to duplicate. > > > Section 6.10.1 > > > > o Addresses in the ACP are not considered sensitive on privacy > > grounds because ACP nodes are not expected to be end-user devices. > > > > I feel like this claim requires additional justification. > > Added: > > All ACP nodes are in one (potentially federated) administrative domain. > They are are assumed to be to be candidate hosts of ACP traffic > amongst each other or transit thereof. There are no transit nodes > less privileged to know about the identity of other hosts in the ACP. Thanks. Hopefully everyone who profiles this stuff to non-managed/enterprise environments will remember to think about this aspect... > > Section 6.10.3.1 > > > > A node knowing it is in a zone MUST also use that Zone-ID != 0 > > address in GRASP locator fields. [...] > > > > What does "also" mean here? Is this another requiment being placed on a > > node that knows it is in a zone, or must this node use both the zone-id==0 > > and the zone-id!=0 addresses in GRASP locator fields (i.e., duplicating all > > such)? > > Just bad english. removed "also". > > > Section 6.10.5 > > > > o V: Virtualization bit: Values 0 and 1 are assigned in the same way > > as in the Zone-ID sub-scheme. > > > > There is not a single 'V bit' -- the V field is either 8 or 16 bits long -- > > so saying "in the same way" is confusing. > > changed to: > > V: Virtualization field: 8 or 16 bit. Values 0 and 1 are assigned in the same way as in the Zone-ID sub-scheme, the other values are for further use by the node. > > > I believe that the intent is to > > distinguish between "zero" and "not-zero", with the zero value meaning the > > same as the zero bit in the Zone-ID sub-scheme. That is, the final bit > > need not be 1 to indicate a "virtual" usage. Or do I misunderstand? > > Right. The sentence just means to express that any semantic we assign > to values 0 and 1 in the zone addressing scheme should equally apply > to values 0 and 1 in the Vlong addressing scheme, leaving the remaining > 8/16 bit - 2 values up for further use by the node. > > > Section 6.10.7.3 > > > > In a simple allocation scheme, an ACP registrar remembers > > persistently across reboots for its currently used Registrar-ID and > > for each addressing scheme (zone with Subnet-ID 0, Vlong with /112, > > Vlong with /120), the next Node-Number available for allocation and > > increases it after successful enrollment to an ACP node. In this > > simple allocation scheme, the ACP registrar would not recycle ACP > > address prefixes from no longer used ACP nodes. > > > > It's probably better to say "increments it during successful enrollment" > > since if the registrar crashed right after issuing a certificate but before > > incrementing the next available node-number, it would issue a duplicate > > when it came back up. > > Done. > > You'd probably want to have another bit on persistent storage saying > allocation pending, so that if you crash and see that bit on recovery, you > know that you don't know if the number got successfully enrolled and you > have to skip it to be sure you don't do duplicate allocation. > > Don't think we want to take all the fun of figuring out the best scheme > from implementers. This is more focussed to operators to understand > enough that they can operate it confidentially. > > > Section 6.10.7.4 > > > > [...] Even when the renewing/rekeying ACP registrar is not > > the same as the one that enrolled the prior ACP certificate. See > > Section 10.2.4 for an example. ACP address information SHOULD also > > be maintained even after an ACP certificate did expire or failed. > > See Section 6.1.3.5 and Section 6.1.3.6. > > > > Both the first and the last sentence quoted have grammar nits; the former > > is a sentence fragment (perhaps "This holds even when [...]"), and the > > second has inconsistent verb tense (perhapse "expired or failed"). > > another case of editor looses, vi wins. > > Split into two hopefully now correct sentences/paragaphs: > > ACP address information SHOULD be maintained even when the renewing/rekeying > ACP registrar is not the same as the one that enrolled the prior ACP certificate. > See for an example. > > ACP address information SHOULD also be maintained even after an ACP > certificate did expire or failed. See > and . > > > Section 6.11 > > > > All routing updates are automatically secured in transit as the > > channels of the autonomic control plane are by default secured, and > > this routing runs only inside the ACP. > > > > Again, I thought encryption was only "very strong SHOULD". > > That point is resolve (MUST). > > > If this "secured" only was intended to refer to authentication (and > > presumably implicitly integrity protection), then "by default" is > > not needed, since the latter protection is mandatory. > > I changed "by default secured" to "encrypted" to make the sentence > easier to digest. > > > Section 6.11.1.1 > > > > In summary, the profile chosen for RPL is one that expects a fairly > > reliable network reasonably fast links so that RPL convergence will > > be triggered immediately upon recognition of link failure/recovery. > > > > Is there a missing "with" in here, or something else in order to get > > it to parse? > > Fixed in prior version. > > > [...] This the same > > behavior as that of other IGPs that do not have the Data-Plane > > options as RPL. > > > > Is this suppposed to be ", as is the case for RPL"? (Also, "This is"?) > > Changed to: > This is the same behavior as that of other IGPs that do not have the Data-Plane options of RPL. > > > In general, this section has an unclear overall structure/organization and > > several instances of strange grammar/wording. The RFC Editor will be of > > some help with the latter, but generally is unwilling to take the > > initiative to make the sorts of changes needed to address the former. > > This was a collaboration between Pascal Thubert and I. I think all the wrong > grammar is from me and all the right technical RPL details from Pascal ;-)) > > If this looks like a strange collection of tidbits, this was the pieces > of information that i felt to be unique to RPL and not known by developers or > operators who are otherwise knowledgable of IGP routing. > > Having said this: Please re-read the section, i did another thorough re-read > and changed a lot of text for better readability. Generally it looks a lot better; thanks. > > Section 6.11.1.7 > > > > Local Repair: As soon as link breakage is detected, send No-Path DAO > > for all the targets that where reachable only via this link. As soon > > > > nit: s/where/were > > Ack. > > > Section 6.11.1.9 > > > > Please don't treat "security" as some single black-box concept; there are > > gradiations within it and different attributes that can be relevant. For > > example, here we would probably say something like "Because the ACP links > > already include provisions for confidentiality and integrity protection, > > their usage at the RPL layer would be redundant, and so RPL security is not > > used". I guess the RPL security bits needed for per-participant > > authentication (as opposed to a group key) are not entirely in place yet, > > so it's hard to claim that RPL security would do much better than even > > hop-by-hop ACP security measures. > > Thanks. Inserted your suggested text. > > Myself, i would have gone with a rant about the ACP trying to eliminate the need to > waste several years of everybodies time to reinvent for each network distributed > protocol its own unique security mechanisms, but thats obviously not necessarily > the most prudent option to quickly pass through IESG. At least not when talking > about existing protocols ;-) > > > Section 6.11.1.12-14 > > > > These sections do not match up with the template entries I see in > > draft-ietf-roll-applicability-template-09; can you explain the discrepancy? > > TBD: I think these where details usually not covered by the RPL profile > but that we felt necessary to add for the case of the ACP. > > > Section 6.12.5 > > > > I'm confused about the "ACP multi-access virtual interface" -- is > > this only for the initial "link-local" flooding/discovery? > > Otherwise, aren't the ACP secure channels inherently two-party? I > > don't think I understand what the multi-access benefit is, since my > > understanding was that RPL was running on top of these link-local > > secure channels. > > The secure channels are just that: packet transport. They are not interfaces > with IPv6 addresses on them recognized by IPv6 forwarding or an IPv6 > routing protocol as an L3 subnet. So we need to define how we add a "virtual" > interface on top of the secure channel and how to operate it. > > If you just do a 1:1 mapping between p2p secure channels and interfaces, > you will end up on a LAN with a full mesh of p2p L3 subnet virtual > interfaces. Which is primarily an issue when you want to flood. Like > RPL and GRASP do. You get a message from one neighbors p2p interface and > you send it back to all the other neighbors p2p interfaces. Which doesn't > break things, its just inefficient. > > Thats why for an optimized implementation, you create a single "LAN" like > virtual subnet across all the secure channels to neighbors on the same > underlying L2 LAN. Then you can send L3 multicast into that multipoint > subnet, and the virtual subnet driver replicates those packets into > all the p2p secure channels, and the receiver won't loop back > packets unnecessarily. > > This optimization technique is done in several network solutions. > Somehow its always a vendor technique, so i couldn't find a good reference > RFC to describe this (outside of something very specialized that didn't > seem right to reference). So i ended up having to write a lot of the > mechanism here ;-( Thanks for the re-explanation; I think it make sense on the third time around at leaset. > > Section 6.12.5 > > > > The ACP virtual interface IPv6 link local address can be derived from > > any appropriate local mechanism such as node local EUI-48 or EUI-64 > > ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend > > on something that is attackable from the Data-Plane such as the IPv6 > > link-local address of the underlying physical interface, which can be > > attacked by SLAAC, or parameters of the secure channel encapsulation > > header that may not be protected by the secure channel mechanism. > > > > Is this the same EUI that might be used on the Data-Plane like the MAC > > address of the physical interface? > > Yes. But MAC address seems to be a slang term, some review had me use > to EUI terminology if i remember correctly. I think I was mentioning it because reusing the same identifier for the data-plane and ACP addressing would potentially leak to an attacker some information about the ACP address(es) in use. The other protections on the ACP are supposed to keep that from being useful in actually attacking the ACP from the data-plane, but it was particularly noteworthy given the context of this paragraph. That said, I don't see any useful way to change the text here. > > nit: s/Charly/Carol/ > > Done. > > > Section 7.2 > > > > The description in the previous paragraph was specifically meant to > > illustrate that on hybrid L3/L2 devices that are common in > > enterprise, IoT and broadband aggregation, there is only the GRASP > > packet extraction (by Ethernet address) and GRASP link-local > > multicast per L2-port packet injection that has to consider L2 ports > > at the hardware forwarding level. The remaining operations are > > purely ACP control plane and setup of secure channels across the L3 > > interface. This hopefully makes support for per-L2 port ACP on those > > hybrid devices easy. > > > > Have you talked to any hardware manufacturers that would be able to remove > > the "hopefully" from this statement? > > Yes. This judgement comes primarily from me investigating the (non-)complexity to > support "per port L2 ACP" on a few ranges of L2/L3 switches hardware at my previous > employer and my background and comparison to the complexity of hardware support > for IGMP/MLD(L3)+IGMP/MLD(L2), signaling and forwarding entries. Okay. > > A generic issue with ACP in L2 switched networks is the interaction > > with the Spanning Tree Protocol. Ideally, the ACP should be built > > also across ports that are blocked in STP so that the ACP does not > > depend on STP and can continue to run unaffected across STP topology > > changes (where re-convergence can be quite slow). The above > > described simple implementation options are not sufficient for this. > > Instead they would simply have the ACP run across the active STP > > topology and the ACP would equally be interrupted and re-converge > > with STP changes. > > > > This "Instead" is a little unclear, perhaps "They fail because the ACP > > simply runs across the active STP topology [...]"? > > Didn't read well, yes. Moved last paragraph to the front and fixed up sentences > so it reads easier. > > A generic issue with ACP in L2 switched networks is the interaction with the Spanning Tree > Protocol. Without further L2 enhancements, the ACP would run only across the active STP > topology and the ACP would be interrupted and re-converge with STP changes. > Ideally, ACP peering should be built also across ports that are blocked in STP so > that the ACP does not depend on STP and can continue to run unaffected across STP topology > changes, where re-convergence can be quite slow. The above described simple implementation > options are not sufficient to achieve this. > > > Section 8.1.1 > > > > The ACP connect interface must be (auto-)configured with an IPv6 > > address prefix. Is prefix SHOULD be covered by one of the (ULA) > > prefix(es) used in the ACP. If using non-autonomic configuration, it > > SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). > > > > I'm confused in what case ACP connect would be used with autonomic > > configuration (and thus why the qualification is needed on the SHOULD). > > I thought the whole thing was premised on the presence of a NMS that does > > not implement ACP. > > Changed to: > > An ACP connect interface SHOULD use an IPv6 address/prefix > from the ACP Manual Addressing Sub-Scheme (), letting the operator configure for example only the Subnet-ID and having the node automatically assign the remaining part of the prefix/address. It SHOULD NOT use a prefix that is also routed outside the ACP so that the addresses clearly indicate whether it is used inside the ACP or not. > > > In the simple case where the ACP uses only one ULA prefix and all ACP > > connect subnets have prefixes covered by that ULA prefix, NMS hosts > > can rely on [RFC6724] > > > > Please include some exposition on the property being provided instead of > > just citing the RFC. > > Improved the salient two sentences: > > NMS hosts can rely on to determine longest match prefix routes towards its different interfaces, ACP and data-plane. With RFC6724, The NMS host will select the ACP connect interface for all addresses in the ACP because any ACP destination address is longest matched by the address on the ACP connect interface. > > > ACP Edge Nodes MUST only forward IPv6 packets received from an ACP > > connect interface into the ACP that has an IPv6 address from the ACP > > prefix assigned to this interface (sometimes called "RPF filtering"). > > > > This sentence is hard to parse as to what the "that has" restriction > > applies to. I think it's supposed to be that you only forward (IPv6 packets > > with a source address from the ACP prefix) into the ACP, right? > > I have a genetic disorder for long sentences. Its called german genes > and upbringing. See Mark Twain *sigh* > > Changed to: > > When an ACP Edge node receives a packet from an ACP connect interface, it > MUST only forward it into the ACP if it has an IPv6 source address from that interface. > This is sometimes called "RPF filtering". > > (somehow i can't shorten it, but hopefully its easier to read). It is (even though "it" is used for both the packet and the edge node), thanks. > > To limit the security impact of ACP connect, nodes supporting it > > SHOULD implement a security mechanism to allow configuration/use of > > ACP connect interfaces only on nodes explicitly targeted to be > > deployed with it (such as those physically secure locations like a > > NOC). For example, the certificate of such node could include an > > extension required to permit configuration of ACP connect interfaces. > > > > I think this would be better as "[...] could include a specific extension, > > and that extension would be required to be present in order to permit > > configuration [...]". But who would enforce this requirement -- the ACP > > implementation on the node that is compromised? That does not seem to > > provide the desired security property. This also falls into Alissa's > > comment about "future work". > > Yes, this was already changed in -17 for Alissa as follows: > > To limit the security impact of ACP connect, nodes supporting it > SHOULD implement a security mechanism to allow configuration/use of > ACP connect interfaces only on nodes explicitly targeted to be > deployed with it (those in physically secure locations such as a > NOC). For example, the registrar could disable the ability to enable > ACP connect on devices during enrollment and that property could only > be changed through re-enrollment. See also Appendix A.10.5. > > Appendix A.10.5 (futures) describes how one could do role assignments > enabling this type of behavior. > > Wrt compromised nodes that you mention: Lets ignore the attack of > running unauthorized code, thats a different discussion and when > you have that attack succeeding, you don't need to worry about ACP connect anyhow. > > Instead, the role assignment described in the current -19 text can IMHO very well > protect against the most important attack, which is the ability to configure anything > on the compromised device. > > > Section 8.2.1 > > > > I think you need to include a reference for ABNF. > > Thought we only do this the first time we encounter ? > Up in the GRASP objective section. Whoops, that was too far ago for me to have remembered. You're right. > > Section 9.1 > > > > [...] Since the revocation check is only > > done at the establishment of a new security association, existing > > ones are not automatically torn down. If an immediate disconnect > > is required, existing sessions to a freshly revoked node can be > > re-set. > > > > How would the revoked node's peers know to perform such a re-set? This > > would seem to require some signaling protocol at revocation time. > > Yes. I think this is part of the original informative text, like a requirement > that we wrote into the spec before getting to the normative part. I think > we never tried to solve this hidden requirement ("benefit"), primarily > because the authors (and brski authors) became more and more fans of > short lived certificates over CRL/OCSP because it minimizes the total number of protocols > required and doesn't seem to increase the overall signaling vs. periodically > refreshed OCSP or CRL. > > So, with that background, here is my proposed rewrite of the paragraph: > > The ACP tracks the validity of peer certificates and tears down ACP secure channels when a peer certificate has expired. When short-lived certificates with lifetimes in the order of OCS > P/CRL refresh times are used, then this allows for removal of invalid peers (whose certificate was not renewed) at > similar speeds as when using OCSP/CRL. The same benefit can be achieved when using CRL/OCSP, periodically refresh > ing the revocation information and also tearing down ACP secure channels when the peers (long-lived) certificate is revoked. There is no requirement against ACP implementations to require this enhancement though to keep the mandatory implementations simpler. > > So, this is just me of course trying to promote the short-lived cert option and > keeping ACP implementations constrained complex. > > There may be established policies in IETF PKI to continue demanding all the > same benefits when using the more complex CRL/OCSP approach, in which case > i'd have to probably remove the last sentence and also add an appropriate > reqiurement to tear down upon CRL/OCSP refresh to the normative text. I don't think there's a general PKIX requirement to check revocation status, though some protocols using PKIX mechanisms do additionally require it. > > After a network partition, a re-merge will just establish the > > previous status, certificates can be renewed, the CRL is available, > > and new nodes can be enrolled everywhere. Since all nodes use the > > same trust anchor, a re-merge will be smooth. > > > > I believe this document has described schemes where not all nodes use the > > same trust anchor [for signing their LDevID], so maybe this should be > > "trust anchor(s)" plural? > > Done. > > > Merging two networks with different trust anchors requires the trust > > anchors to mutually trust each other (for example, by cross-signing). > > As long as the domain names are different, the addressing will not > > overlap (see Section 6.10). > > > > Subject to the risk of a 40-bit collision in SHA256! While not necessarily > > a critical flaw at this time, the limitation should probably be mentioned. > > Right. Added: except for the low probability of a 40-bit hash collision in SHA256. The current wording "As long as the routing-subdomain hashes are different, the addressing will not overlap, except for the low probability of a 40-bit hash collision in SHA256" takes a bit of work to tease apart. It's not technically incorrect (the hashes can be different but share a 40-bit initial prefix), but readers might take "routing-subdomain hashes" to mean the post-truncation hash, in which case we might want to s/except for the low probability/which only happens in the unlikely event/. > Alas the nice web pages where you could "register" your ULA prefix went > away 2 yers ago. I had them mentioned in earlier versions of the doc. > > Btw: there is nothing limiting AXCP to ULA. If there was a simple > "pay with credit card to get a /48 prefix" service, we'd probably have > included a configurable prefix option. But i don't even know how expensive > such a prefix would be these days. > > > Section 9.2.1 > > > > I think you need informative references to all the listed protocols that > > the ACP could serve as protection for. > > Done. > > > % remote attacks are impossible > > > > Remote attacks to DoS by resource consumption the nodes involved would > > still work fine, so "impossible" is probably overstating it. > > refined sentence to: > > remote attacks from the data-plane are impossible as long as the data plane has no facilities to remotely sent IPv6 link-local packets. The only exception are ACP connected interfaces which require higher physical protection. > > The point is that the only way to get into the ACP is through the link-local addresses of the ACP secure channels and it should be impossible to do that remotely. > > > Section 9.2.2 > > > > I expected to see something about the importance of being able to detect a > > compromised node and revoke its certificate. Ideally this could be > > automated (with the detecting node providing proof of compromise in some > > fashion), though the details of that would probably be hard to get right. > > Note that the -18 already had changes to 9.2.2 fixing some text, but i > also created a new appendix A.10.8 in response to your wish. I am not > sure if it highlights enough what you have in mind, and i am sure its > not what folks wanting more autonomic networks would prefer, but IMHO the > most likely short-term valuable direction is to focus on eliminating all > the local options to break into a network devices through credential abuse > and configuration change that can't be rectified. Or else: Maximize > the options to recover a node remotely from attackers before going to the > option of giving it up by kicking it off the network. > > Would love to hear your thoughts on this. I think you landed in the right area -- thanks! > > Section 9.3 > > > > "independent of configuration" is in conflict with the discussion of > > configuring ACP connect, configured remote ACP neighbors, etc. > > Yes. i added (intended to be) independent of configuration. > > Hope i don't need to add more explanations to the fact that we need > to distinguish between functionality we can fully automate without > config and the aspects where we do not yet have such a solution. > In most networks, ACP is fully autonomic except for a few (redundant) > registars with ACP connect, so the real benefit is larger than > what the draft may make it look like. > > > Section 10.2.2 > > > > For BRSKI or other mechanisms using vouchers: Parameters to > > determine how to retrieve vouchers for specific type of secure > > bootstrap candidate ACP nodes (such as MASA URLs), unless this > > information is automatically learned such as from the LDevID of > > candidate ACP nodes (as defined in BRSKI). > > > > I thought the LDevID was essentially synonymous with "ACP domain > > certificate" in this document, so I can't understand what this means > > (unless IDevID was intended). > > Yes, typo. IDevID was meant. The voucher RFC defined a MASA URL option. > Fixed. I think you fixed a different instance than I quoted (so it's duplicated in my new ballot comments). Eventually between the two of us we'll catch them all, right? > > Section 10.2.3 > > > > [...] And without additional centralized tracking of > > assigned certificates there is no way to do this - assuming one can > > not retrieve this information from the . > > > > Missing the end of the sentence? > > Fixed in prior version (just removed the part starting from -, it was trash). > > > Section 10.2.4 > > > > Or let it expire and not renew it, when the certificate of the sub-CA > > is appropriately short-lived. > > > > This sort of sentiment has been highly controversial in other contexts > > (e.g., draft-nir-saag-star). (Also, that's a sentence fragment.) > > Fixed sentence intro: Alternatively one can let it expire and not renew it... > > Wrt to controversy of short lived certificate: From my memory participating > in the effort as a co-author, the controversy is about not having working > automated certificate renewal systems where it is feasible to set cert > expiry times to the same time-scale are refresh/polling of CRL/OCSP updates. > Which seems to be typically in the order of minutes (15 minutes... 30 minutes). > With ACP+EST we feel very confident that the overall complexity of short lived > cert renewal is overall actually lower than CRL/OCSP polling. Cool! > > Therefore ACP domain membership for an ACP node enrolled from a > > compromised ACP registrar will fail. > > > > >From a compromised *and detected* registrar. > > Fixed. > > > Section 10.3.x > > > > This whole section feels more like a sketch of an idea than a > > well-specified model or protocol. It might be better if spun off into a > > separate document, with time spent to produce (e.g.) a YANG module or state > > machines for devices in various states. > > This is based on operatsional experience gained from the commercial implementation > and extrapolating from here. Its certainly true that i would want to go overboard > in specificity in an informal text like this, because its a lot easier to nail > down details in a YANG model. I think it would be good to have this conceptual > description out in the field, so that we can get more people think about it > before finalizing a YANG model in a separate document. > > I have no strong opinion about outsourcing this into a separate document > except that i have also heard WG participants wanting to have this information > in the ACP document. And it would be somewhat breaking the documentation > in a strange place. If you feel strongly about this, i would suggest to > break out the whole section 10 into an ACP operational model document > as long as its clear that nobody would start raising the expectation that > the main ACP specification must have a normative reference to the new operational > document (but only an informational one)- because i really would like > to finish an ACP RFC, and i can already see how we're open the floodgates > for a lot more operation text when we move 10 into a separate document. 10.3.x specifically feels less-baked than the rest of 10, to me, but I'm not going to insist on changes here. > > Section 10.3.5.1 > > > > [...] Automatic enablement of ACP/ANI in networks > > where the operator does not only not want ACP/ANI but where he likely > > never even heard of it could be quite irritating to him. Especially > > when "down" behavior is changed to "admin down". > > > > The behavior mentioned in this last sentence really ought to be called out > > more clearly in the previous section as changing the semantics of existing > > administrative controls. > > Not quite clear which section you mean, can you propose what text to insert > where ? There is a lot of text in the earlier part of 10.3 discussing the > pro/cons of down vs. admin down. I was thinking the toplevel 10.3.5; adding another sentence at the end that flatly states "this is a change in behavior for the 'down' command and would need to be clearly conveyed to the administrator". But I may not have had the full 10.3.x context in my head when I wrote that, so if you think it's okay as-is, that's plausible. > > Section 10.3.7 > > > > The control names indicated within double quotes are mostly incomplete > > references; it seems better to say, e.g., """the "up-if-only" option for > > node-level ACP/ANI enablement""". > > Not sure i completely understood what you meant. Pls. check. I think I was concerned about: If the option "up-if-only" is not selected, interfaces enabled for ACP/ANI interpret "down" state as "admin down" and not "physical down". In "admin-down" all non-ACP/ANI packets are filtered, but the physical layer is kept running to permit ACP/ANI to operate. since I was confused about what scope "up-if-only" applied to. (But I was somewhat generally confused when reading this section, and it may have just been my fault and not the document's.) > Changed to for example: If the "up-if-only" option of that command is not selected,... > > > Section 11 > > > > An ACP is self-protecting and there is no need to apply configuration > > to make it secure. Its security therefore does not depend on > > configuration. > > > > It seems like there are some higher-level/potentially "external" > > configurations needed, including but not limited to: setting up the > > registrar, definng the Intent, assigning a ULA to use for the domain, > > policy for the CA issuing domain certificates, and any interaction with > > external systems that is needed. (That is, a fully autonomous system would > > be totally self-contained, and thereby not of much use to the humans > > involved!) > > Let me explain how us authors cam up with that statement. > Here is how simple/autonomic ANI (ACP+BRSKI) can be with existing spec alone: > > | -> Select an ANI server-router. > | Configure "autonomic-network-server " > | "autonomic-connect ethernet 1/1" > | > | -> Plug together a network of greenfield routers (no config, fresh from factory) > | BRSKI bootstraps all routers, ACP comes up. No data-plane whatsoever. > | > | -> Connect management station to server-router ethernet 1/1 > | Manage / provision network through ACP using ssh/netconf/whatever > | > | Under the hood, server-router config simply creates an autonomic registrar > | and a CA with self-signed root cert, allocates ULA prefix from domain-name, > | an registers any greenfield devices registering. Then these devices > | hop-by-hop create ACP. > | > | The CLI of a commercial ANI implementation is very similar and as simple. > > Does this give you a better sense of the reasoning behing the statement made ? I think my confusion is mostly about how tightly the "server-router" is integrated with the ACP and ANI. My mental model has existing off-the-shelf NMSes that are not tightly integrated, so you need ACP-connect to inject (e.g.) registrar and CA configuration into the ACP. But your description makes it sound more tightly integrated already than I expected. > As you said, if the operator wants more policies, he has to configure them, > but anything configured is either outside of scope of ACP (CA policies), > or it is explicitly from section 8 "support for Non-ACP components". > > Alas, its hard to see the simplicity possible in the product when ony > reading the spec that specifies all the gory details of what happens > under the hood and of course needs to spend more on the difficult / non-autonomic > pieces than the main part which is simple and autonomic. > > With hat being said, here is the rewritten initial statement to be hopefully > more precise: > > After seeding an ACP by configuring at least one ACP registrar with routing-subdomain and a CA, an ACP is self-protecting and there is no need to apply configuration to make it secure. Its security therefore does not depend on configuration. This does not include workarounds for non-autonomic components as explained in . > > > "correct operation" to me usually means "this system is behaving as > > expected", but I think the intended usage here is more like "being operated > > and managed correctly". I don't know if I'm enough of an outlier to make > > it not worth changing the text. > > You did not give a reference for this concern. I could only find the following > text at the end of the security section: > > | Fundamentally, security depends on correct operation, implementation and architecture. Autonomic approaches such as the ACP largely eliminate the dependency on correct operation; > > So i changed this as follows: > > | Fundamentally, security depends on avoiding operator and network operations automation mistakes, implementation and architecture. Autonomic approaches such as the ACP largely eliminate operator mistakes and make it easier to recover from network operations mistakes. Implementation and architectural mistakes are still possible, as in all networking technologies. You found the right place and made a good change. Sorry for being vague. > > I would like to see more text about the scope of damage that a compromised > > ACP node can do, and suggesting detection/remediation measures. > > Ok, i have revisited and rewritten salient text about this in the security section > starting with "The ACP It is designed to enable automation of current network management and future autonomic peer-peer/distributed network automation" - up to above paragraph (Fundamentally...) > > Please review. I hope it correctly captures the high-level aspect of the problem. I think it does. > Most fundamentally: We started designing ACP against the expectation of future fully autonomic networks being very much an extrapolation of todays fully distributed services in networks (like routing) therefore having simple group-security. We did along te way recognize the growing interest in automation for entralized network manaement where it is simple to assign two clases of roles. Both of these models are easily realized with the ACP, but the more generic model encompassing a variety of more flexible authorization and role options is IMHO still open. > > > Section 12 > > > > Note that the objective format "SRV." is intended to be > > used for any that is an [RFC6335] registered service > > name. This is a proposed update to the GRASP registry subject to > > future work and only mentioned here for informational purposed to > > explain the unique format of the objective name. > > > > I'm confused about what this is actually trying to say. It sounds like it > > is actually registering SRV.est (in the previous paragraph), but following > > that up by saying that this isn't actually a real registered service name > > yet, and we're just registering the objective name proactively for future > > work? If so, that does not seem like the correct thing to do. > > I think this was answered by me on top of this mail. > We are registering a real service name. We just explain that we want to > simplify the future IANA registration process and hence we use service > names whose template format indicates rfc6335 pre-registered service-names > > > Section A.2 > > > > [...] This requires only that the BRSKI > > registrar honors expired domain certificates and that the pledge > > first attempts to perform TLS authentication for BRSKI bootstrap with > > its expired domain certificate - and only reverts to its IDevID when > > this fails. > > > > The "first" is unclear -- perhaps "that the pledge attempts to perform TLS > > authentication for BRSKI bootstrap using its expired domain certificate > > before falling back to attempting to use its IDevID for BRSKI"? > > Done. Thanks. > > > Section A.4 > > > > [...] RPL also has other scalability improvements, > > such as selecting only a subset of peers instead of all possible > > ones, and trickle support for information synchronization. > > > > (But trickle support is not used in the ACP profile of RPL.) > > Removed. > > > Section A.8 > > > > This discussion of reusing preexisting MAC addresses violates the claim > > that the ACP-internal addresses are not guessable from the data plane. > > True. I inserted this text on behalf of use cases brought to us authors, > which i think are primarily inside what those customers call physcially > secure environments, so i think derived work might be happy to compromise > more on security to improve ease of diagnostics. > > If you ask me: > > This documents security is really the best security we can do for the > original core use case of full autonomic peer-to-peer distributed > automation. All the follow-on work will either try to improve security > for more structured role-based automation and/or reduce security for > specific market segments to accelerate adoption. I hope I was not coming across as saying that the security properties as specified are insufficient! I think my main concerns have just been about making sure that we're accurate and consistent in how we talk about them. -Ben > ---- > > Thanks a lot for your really very thorough and thoughtfull review. > I hope my answers are satisfactory and we can move forward with the > document. From nobody Tue Jul 16 15:48:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B99120162; Tue, 16 Jul 2019 15:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 6Saew3xoBweX; Tue, 16 Jul 2019 15:48:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAEB12002F; Tue, 16 Jul 2019 15:48:25 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6GMmKVc025123 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Jul 2019 17:48:22 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563317304; bh=esA1TV7zfa7ZFugEqSFvf8yu0M9BvSazScqDlDEwFE8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FvLwLniSVpGrd35nd1GuJN2Rw/zmbwxvTdfIHHzprbU+UD73lZMPb0iGfFB277dNG KXst8LBotMLfg4X5S9p8UjjR2OSXO/4B024y11L5aD9dsXjF4syQdQA4RXKR/jeOhS HlfL1KygiBB1tlBDXMQuwd4WUL9JWYC2X20/ibn0= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson , Benjamin Kaduk Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <12747.1563315277@localhost> From: Adam Roach Message-ID: Date: Tue, 16 Jul 2019 17:48:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <12747.1563315277@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:48:26 -0000 On 7/16/19 5:14 PM, Michael Richardson wrote: > Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > ... > This is an rfcdiff from the already-wrapped JSON to the proposed -23 that > includes all the changes from the various DISCUSSes up to now: > https://tinyurl.com/y2qhjwh8 As a quick note -- the diff above does not address the "discuss" part of my second discuss point: the document remains ambiguous regarding *how* the URL is to be returned. The lengthy parenthetical references added to the corresponding paragraph aren't sufficient to positively indicate that the URL appears in a "Location" header: this needs to be stated explicitly rather than implied by a section reference. /a From nobody Tue Jul 16 15:54:45 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5262B12002F; Tue, 16 Jul 2019 15:54:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.4 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156331768227.15267.2488890611024053018.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2019 15:54:42 -0700 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:54:43 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [trimming to just the topics still under discussion; no change to the text of the remaining items even though some changes have been made to the document] I think there needs to be some justification of why rfc822Name is chosen over a more conventional structure in the otherName portion of the subjectAltName, which is explicitly designed to be extensible. In a few places, the MTI cryptographic mechanisms are under-specified, whether the cipher mode for IKE or the TLS ciphersuites. I have attempted to note these locations in my section-by-section comments. Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL root, but if I understand correctly the RPL root is automatically determined within the ACP, and thus the operator does not a priori know which node will become the RPL root. Am I misunderstanding, or is this effectively placing this requirement on all ACP nodes? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for adding the implementation experience note to the shepherd writeup; it is helpful to understand the maturity level of the document. The comments here are probably best understood in the context of my previous ballot position, specifically with respect to certain topics being "speculative" or a matter for "future work". One somewhat general comment that occurred to me on the reread is that by encoding the ACP address into a node's LDevID, we are on the face of things locking it into a given addressing model, though in practice it should be fairly straightforward to issue a new certificate through regular update/renewal mechanisms. I forget if we have discussion of this non-issue already. Section 1 Combining ACP with Bootstrapping Remote Secure Key Infrastructures (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the "Autonomic Network Infrastructure" as defined in [I-D.ietf-anima-reference-model], which provides autonomic connectivity (from ACP) with fully secure zero-touch (automated) bootstrap from BRSKI. The ANI itself does not constitute an nit: It's unclear that there's universal agreement about what "fully secure" might mean, so I'd suggest just using "secure". Section 2 ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate (LDevID) carrying the domain information field which is used by nit: I think the reference is for "certificate", not "provisioned". ACP secure channel: A cryptographically authenticated and encrypted data connection established between (normally) adjacent ACP nodes to carry traffic of the ACP VRF secure and isolated from Data- Plane traffic in-band over the same link/path as the Data-Plane. nit: I'm not sure if "secure" or "securely" is better (but what does "secure from" mean?) Enrollment: The process where a node presents identification (for example through keying material such as the private key of an IDevID) to a network and acquires a network specific identity and trust anchor such as an LDevID. nit: the LDevID is the identity; it's not a trust anchor. Section 5 3. For each node in the candidate peer list, it authenticates that node (according to Section 6.1.2) and negotiates a mutually acceptable channel type. 4. For each node in the candidate peer list, it then establishes a secure tunnel of the negotiated type. The resulting tunnels are then placed into the previously set up VRF. This creates an overlay network with hop-by-hop tunnels. nit: the "channel type" of (3) is the "negotiated type" of the "secure tunnel" in (4), right? It might be nice to use the same word in both items, to help tie the language together. Section 6 nit: "must have it's ACP domain certificate" gained an apostrophe in "it's" but the original "its" was correct. Section 6.1 members. The LDevID is used to cryptographically authenticate the membership of its owner node in the ACP domain to other ACP domain members, the TA is used to authenticate the ACP domain membership of other nodes (see Section 6.1.2). nit: comma splice The ACP does not mandate specific mechanisms by which this keying material is provisioned into the ACP node, it only requires the Domain information field as specified in Section 6.1.1 in its domain certificate as well as those of candidate ACP peers. See nit: comma splice The ACP domain certificate SHOULD be used for any authentication between nodes with ACP domain certificates (ACP nodes and NOC nodes) where the required condition is ACP domain membership, such as ACP nit(?) I'd suggest s/required condition/required authorization condition/ Section 6.1.1 The ABNF in Figure 2 seems to have multiple what I'll call for lack of a better term "terminal constructions" (i.e., routing-subdomain and domain-information) that are not used in other rules. Some text on which one is used in the rfc822Name and which is just informational for other purposes is probably in order. o The maximum size of "domain-information" is 254 characters and the maximum size of node-info is 64 characters according to [RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). nit: I don't think we refer to node-info anywhere. On the topic of rfc822Name vs. otherName, I note that there's no requirement to use ASN.1 for the internal structure of the value; it's perfectly acceptable to make it an OCTET STRING and shove a more-friendly data structure in there. (It's a little bit weird in terms of mental models, but funny looks aside, it's pretty common.) If the other structure is fixed-length, there is not any actual ASN.1 knowledge required by the recipient; they just check that the length is right and the data starts with the correct fixed prefix (corresponding to the OID and ASN.1 length encoding), before processing the encoded data in whatever manner is appropriate. Since we want to put domain names in, fixed-length is probably out of the figure, but even if we're limited to what openssl provides, getting an ASN1_OCTET_STRING and extracting its contents to a pointer+length is pretty well established; we don't need to make people learn about ASN1_SEQUENCE() at all. So you could have the fundamental structure of the otherName be something like: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Flags |M|A| +---------------------------------------------------------------+ | | + + | | + [acp-address] + | | + + | | +---------------------------------------------------------------+ | rsub-len | rsub... | +------------------------------+ + ~ ~ +---------------------------------------------------------------+ | acp-domain-len | acp-domain... | +------------------------------+ + ~ ~ +---------------------------------------------------------------+ | [TLV extensions] | +---------------------------------------------------------------+ where M means that the holder of the cert is allowed to establish an ACP secure channel (what the '0' acp-address does in the present formulation) and A means that the acp-address field is present and just pack that into an OCTET STRING. Is the rfcSELF@acp.example.com email address for human use really providing much value? This is pretty clearly breaking an abstraction barrier, from my point of view. It also makes acp-domain-name a valid e-mail target across all routing-subdomains. nit: rfcSELF@acp-domain-name o It should be possible to share the LDevID with other uses beside the ACP. Therefore, the information element required for the ACP should be encoded so that it minimizes the possibility of creating incompatibilities with such other uses. otherName with an ACP-specific OID has zero possibility of collisions with other uses; reusing rfc822Name has nonzero possibility of collision. (Note that having multiple otherNames is allowed.) o The information for the ACP should not cause incompatibilities with any pre-existing ASN.1 software. This eliminates the introduction of a novel information element because that could require extensions to such pre-existing ASN.1 parsers. Even getting to the rfc822Name requires some level of ASN.1 parsing, so it's unclear how strong this argument really is. o The element required for the ACP should not be misinterpreted by any other uses of the LDevID. If the element used for the ACP is interpreted by other uses, the impact should be benign. [OIDs are by construction unique] o At minimum, both the AN domain name and the non-domain name derived part of the ACP address need to be encoded in one or more appropriate fields of the certificate, so there are not many alternatives with pre-existing fields where the only possible conflicts would likely be beneficial. It's even possible to define multiple OIDs for otherName use, one for acp-domain-name, one for rsub, etc.. But that feels kind of like overkill to me. Section 6.1.2 3: The peer's certificate passes certificate path validation as defined in [RFC5280] against one of the Trust Anchors associated with the ACP nodes ACP domain certificate (see Section 6.1.3 below). nit: "node's" possessive 4: If the node certificate indicates a Certificate Revocation List (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or Online Certificate Status Protocol (OCSP) responder ([RFC5280], section 4.2.2.1), then the peer's certificate must be valid according to those criteria: An OCSP check for the peer's certificate across the ACP must succeed or the peer certificate must not be listed in the CRL retrieved from the CDP. [...] side note: we could (but don't have to) note that OCSP stapling is a way to get an OCSP response to check. 5: The peer's certificate has a syntactically valid ACP domain information field (encoded as subjectAltName / rfc822Name) and the acp-domain-name in that peer's domain information field is the same as in this ACP node's certificate (lowercase normalized). (Writing this as "has an otherName subjectAltName using the ACP OID" seems more concise to me, but I'll try to stop beating that horse.) When an ACP node learns later via OCSP/CRL that an ACP peers certificate for which rule 4 had to be skipped during ACP secure channel establishment is invalid, then the ACP secure channel to that peer SHOULD be closed even if this peer is the only connectivity to access CRL/OCSP. The ACP secure channel connection MUST be retried periodically to support the case that the neighbor aquires a new, valid certificate. nit: we could probably tighten up the writing here about "MUST be retried periodically" in terms of needing to reestablish the TLS connection provisionally and repeat the initial connection steps, though on second read the current text seems better than I thought on first read. Only when checking a candidate peer's certificate for the purpose of establishing an ACP secure channel, one additional check is performed: nit: I'd suggest s/Only when/When/ Formally, the ACP domain membership check includes both the authentication of the peers certificate (steps 1...4) and a check authorizing this node and the peer to establish an ACP connection and/or any other secure connection across ACP or data-plane end to end. Step 5 authorizes to build any non-ACP secure connection between members of the same ACP domain, step 5 and 6 are required to build an ACP secure channel. For brevity, the remainder of this document refers to this process only as authentication instead of as authentication and authorization. I'd prefer to see a penultimate sentence along the lines of "Other authorization models are possible by local policy, but for this specification (and to some extent, autonomic systems in general), domain membership is deemed sufficient authorization for all operations." Section 6.1.3 A certificate path is a chain of certificates starting at a self- signed certificate of a so called root-CA or Trust Anchor, followed nit(?): I'm used to seeing chain construction start at the leaf/end-entity and chain up to the root, but to some extent this is an editorial question. A single owner can operate multiple independent ACP domains from the same set of private trust anchors (CAs) when the ACP Registrars are trusted not to permit certificates with incorrect ACP information fields to be signed. Such as ACP information with a wrong acp-domain field. [...] nit: This last sentence is a sentence fragment (I suggest joining it to the previous one with a comma). Section 6.1.4 with its ACP domain certificate. When BRSKI (see [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of the BRSKI registrar from the BRSKI TLS connection SHOULD be remembered and used for the next renewal via EST if that registrar also announces itself as an EST server via GRASP (see next section) on its ACP address. IIUC, the BRSKI spec currently advertises BRSKI registrars with the EST-TLS objective, and I don't really understand how this interacts with SRV.est or whether this text should change. Section 6.1.4.1 The objective name "SRV.est" indicates that the objective is an [RFC7030] compliant EST server because "est" is an [RFC6335] registered service name for [RFC7030]. Objective-value MUST be ignored if present. Backward compatible extensions to [RFC7030] MAY be indicated through objective-value. Non [RFC7030] compatible certificate renewal options MUST use a different objective-name. I'd consider adding some text about ignoring unrecognized objective-values, to attempt to preserve the usability of this extension point. Section 6.1.4.3 The ACP node SHOULD support Certificate Revocation Lists (CRL) via HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) My understanding is that HTTP-not-s is commonly used for CRL distribution since the CRL content itself is signed, and there would be a risk of a circular dependency in validating the server's TLS certificate to get to the CRL information. HTTPs connections. The connecting ACP node SHOULD verify that the CDP certificate used during the HTTPs connection has the same ACP address as indicated in the CDP URL of the nodes ACP domain certificate if the CDP URL uses an IPv6 address. nit: "node's" possessive. Section 6.1.4.5 enrollment. Using the ACP node's domain certificate allows the BRSKI registrar to learn that nodes ACP domain information field, so that nit: "node's" possessive. with its old ACP certificate. The re-enrolling candidate ACP node SHOULD only request a voucher from the BRSKI registrar when this authentication fails during TLS connection setup. I might suggest "SHOULD only fall back to requesting a voucher". Section 6.1.4.6 An ACP domain certificate is called failing in this document, if/when the ACP node can determine that it was revoked (or explicitly not renewed), or in the absence of such explicit local diagnostics, when the ACP node fails to connect to other ACP nodes in the same ACP domain using its ACP certificate. For connection failures to nit: maybe "the ACP node to which the certificate was issued", since when I first read this I was expecting it to be about telling that some other node's certificate is failing, not a node's own certificate. Section 6.5 At this time in the lifecycle of ACP nodes, it is unclear whether it is feasible to even decide on a single MTI (mandatory to implement) security association protocol across all ACP nodes. (This is a future-looking statement that implies uncertainty in the current spec.) [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, therefore Node 1 considers itself Bob and Node 2 Alice on connection C1, but they also identify that C2 is to the I think this first "Node 2" should be "Node 1"? interface" that they both connect to. An autonomic node must not assume that neighbors with the same L2 or link-local IPv6 addresses on different L2 interfaces are the same node. This can only be determined after examining the certificate after a successful security association attempt. This could potentially be a "MUST NOT". Section 6.7.1.1 To run ACP via IPsec natively, no further IANA assignments/ definitions are required. An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and peer link-local IPv6 addresses used for encapsulation. It MUST then support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 hash and MUST NOT permit weaker crypto options. Key establishment MUST support ECDHE with P-256. I don't think "SHA256 hash" is quite specific enough (and we probably want GMAC for integrity anyway). Section 6.7.1.2 To run ACP via GRE/IPsec, no further IANA assignments/definitions are required. An ACP node that is supporting ACP via GRE/IPsec MUST then support IPsec security setup via IKEv2, IPsec transport mode, local and peer link-local IPv6 addresses used for encapsulation, ESP with AES256 encryption and SHA256 hash. Why is IPsec/GRE using AES256/SHA256 when IPsec native is using AES256-GCM? Section 6.7.2 We define the use of ACP via DTLS in the assumption that it is likely the first transport encryption code basis supported in some classes of constrained devices. nit: I don't think "basis" is quite the right word, here; maybe "base" (or collapsed back to "codebase" as one word) or omit it entirely. Section 6.7.3 support DTLS. An ACP node connecting an area of constrained ACP nodes with an area of baseline ACP nodes MUST therefore support IPsec and DTLS and supports therefore the baseline and constrained profile. nit: this could probably work just fine as a non-normative "must", since it's just describing facts. Section 6.8.2 nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces" in the second box from the top. ............................................................... . | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ACP interfaces/addressing . . | | | . . | | | A . | ACP-Loopback Interf.| <- ACP Loopback interface C . | ACP-address | - address (global ULA) P . subnet1 | subnet2 <- ACP virtual interfaces . . link-local | link-local - link-local addresses . ............................................................... I'm still a bit confused by this box in the figure -- is the "Users of ACP" label supposed to apply to the previous box(es) or the current one? If the former, it's confusing to see the "ACP security and transport substrate for GRASP" being described as a "user of ACP". GRASP unicast messages inside the ACP always use the ACP address. Link-local addresses from the ACP VRF must not be used inside objectives. GRASP unicast messages inside the ACP are transported via TLS 1.2 ([RFC5246]) connections with AES256 encryption and SHA256. Mutual authentication uses the ACP domain membership check defined in (Section 6.1.2). Just "AES256 encryption and SHA256" describes quite a few TLS ciphersuites (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4); I'd suggest limiting to a specific handful like "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" (the "Recommended" column in the registry will be helpful at picking things). It's probably also useful to specify a RSA/ECDSA key size (and elliptic curve for ECDSA) and the nature of the ECDHE or DHE. Section 6.8.2.1 If GRASP peer connections would just use TCP, compromised ACP members could simply eavesdrop passively on GRASP peer connections for whom they are on-path ("Man In The Middle" - MITM). Or intercept and nit: I'd suggest "were to use just TCP". modify them. With TLS, it is not possible to completely eliminate nit: sentence fragment Section 6.10 Links inside the ACP only use link-local IPv6 addressing, such that each nodes ACP only requires one routable virtual address. nit: "node's" possessive. Section 6.10.2 o Establishing connectivity between different ACP (different acp- domain-name) is outside the scope of this specification. If it is being done through future extensions, then the rsub of all routing-subdomains across those autonomic networks need to be selected so their hashes do not collide. For example a large nit: the grammar could be more clear that it's hash(routing-subdomain) that must be collision-free, rather than hash(rsub) Section 6.10.7.2 information - ACP domain-name, ACP-address, and so on. If the ACP registrar uses BRSKI, it signals the ACP domain information field to the Pledge via the EST /csraddrs command (see [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR Attributes"). I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030 (and the section number is probably stale as well, as the RFC Editor note attests). Oh, but /csrattrs is very close, so this is likely just a typo. Section 6.10.7.3 scheme. The first address of the prefix is the ACP address, all other addresses in the prefix are for other uses by the ACP node as described in the zone and Vlong addressing sub scheme sections. The nit: comma splice policy. For example, in BRSKI, the ACP registrar is aware of the IDevID of the candidate ACP node, which contains a serialNnumber that is typically indicating the nodes vendor and device type and can be nits: "serialNumber", "node's vendor" possessive ACP registrars SHOULD default to allocate ACP zone sub-address scheme addresses with Subnet-ID 0. Allocation and use of zone sub-addresses with Subnet-ID != 0 is outside the scope of this specification nit: it's only referred to as "Subnet-ID" in the manual addressing sub-scheme; for the zone addressing sub-scheme it's "Zone-ID". Section 6.11.1.1 Additionally, failed ACP tunnels can be quickly discovered the secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. This nit: missing word, maybe "through the secure channel protocol" Section 6.11.1.9 [RFC6550] security not used, substituted by ACP security. Because the ACP links already include provisions for confidentiality and integrity protection, their usage at the RPL layer would be redundant, and so RPL security is not used. The ACP links provide only hop-by-hop security, but it looks like at least some of the RFC6550 mechanisms provide more global source authentication. (I'm not suggesting we change the protocol to use RPL security, just noting that this text is not quite right about being entirely redundant.) Section 6.11.1.14 I still think it's worth calling out that the RPL root is not necessarily preconfigured and this "SHOULD" requirement could potentially apply to any node, but this is only Comment-level and you should feel free to ignore it. Section 6.12.5 Care must also be taken when creating multi-access ACP virtual interfaces across ACP secure channels between ACP nodes in different domains or routing subdomains. The policies to be negotiated may be described as peer-to-peer policies in which case it is easier to create ACP point-to-point virtual interfaces for these secure channels. nit: the text is unclear about what sort of policies are being negotiated. Section 8.1.1 When an ACP Edge node receives a packet from an ACP connect interface, it MUST only forward it intot he ACP if it has an IPv6 nit: "into the" Section 9.1 when using OCSP/CRL. The same benefit can be achieved when using CRL/OCSP, periodically refreshing the revocation information and also tearing down ACP secure channels when the peers (long-lived) certificate is revoked. There is no requirement against ACP nit: "peer's" possessive partition is left with one or more of such ACP registrars, it can continue to enroll new candidate ACP nodes as long as the ACP registrars sub-CA certificate does not expire. Because the ACP nit: "registrar's sub-CA" possessive Section 9.2.2 not the Data-Plane. Especially for those management plane functions that have no good protection by themselves because they do not have secure end-to-end transport and to whom ACP does not only provides automatic reliable connectivity but also protection against attacks. nit: s/does not only/not only/ Section 9.3 An ACP is self-forming, self-managing and self-protecting, therefore has minimal dependencies on the administrator of the network. Specifically, since it is (intended to be) independent of configuration, there is no scope for configuration errors on the ACP itself. The administrator may have the option to enable or disable nit: Given that Section 8.2.1 talks about configuring ACP neighbors and 8.2.2 about configuring tunneled neighbors, I'd suggest to s/no scope/only limited scope/, and perhaps similar tweaks in the following paragraphs. Section 10.1 o Check the validity of the domain certificate: * Does the certificate authenticate against the trust anchor? nit: s/authenticate/validate/ - The neighbors certificate does not have the required trust anchor. Provide diagnostics which trust anchor it has (can identify whom the device belongs to). - The neighbors certificate does not have the same domain (or no domain at all). Diagnose domain-name and potentially other cert info. - The neighbors certificate has been revoked or could not be authenticated by OCSP. - The neighbors certificate has expired - or is not yet valid. nit: s/neighbors/neighbor's/ (every time) Section 10.2.2 For BRSKI or other mechanisms using vouchers: Parameters to determine how to retrieve vouchers for specific type of secure bootstrap candidate ACP nodes (such as MASA URLs), unless this information is automatically learned such as from the LDevID of candidate ACP nodes (as defined in BRSKI). I thought the LDevID was essentially synonymous with "ACP domain certificate" in this document, so I can't understand what this means (unless IDevID was intended). Section 10.2.3 Even when such a malicious ACP registrar is detected, resolving the problem may be difficult because it would require identifying all the wrong ACP domain certificates assigned via the ACP registrar after it was compromised. And without additional centralized tracking of assigned certificates there is no way to do this. side note: RFC 6962-style certificate transparency is a somewhat decentralized way to do such tracking, though I do not think the engineering tradeoffs favor trying to use it for this situation. Section 10.2.5 Which candidate ACP node is permitted or not permitted into an ACP domain. This may not be a decision to be taken upfront, so that a per-serialNumber policy can be loaded into ever ACP registrar. nit: "every" Section 10.3.x I still think the document quality here is not as mature as the majority of the document, though concede there is value in covering these topics to some extent in the initial work. Section 10.3.5 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will operate interface where "ACP/ANI enable" is set. Setting of nit: "operate on interfaces where" Section 10.3.5.1 Automatically setting "ANI enable" on brownfield nodes where the operator is unaware of it could also be a critical security issue depending on the vouchers used by BRKSI on these nodes. An attacker could claim to be the owner of these devices and create an ACP that the attacker has access/control over. In networks where the operator explicitly wants to enable the ANI this could not happen, because he would create a BRSKI registrar that would discover attack attempts. Nodes requiring "ownership vouchers" would not be subject to that attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that a global "ACP enable" alone is not subject to these type of attacks, because it always depends on some other mechanism first to provision domain certificates into the device. It's probably worth double-checking that all of these details are still synchronized with RFC 8366 and the current state of BRSKI. Section 10.3.6 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the reliable operations of the ACP if it can be executed by mistake or unauthorized. This behavior could be influenced through some additional property in the certificate (e.g., in the domain information extension field) subject to future work: In an ANI [I don't know if it was intentional or an omission to leave this "future work" note in place when most others were removed.] Section 10.4 There is no desirable configuration for the ACP. Instead, all parameters that need to be configured in support of the ACP are limitations of the solution, but they are only needed in cases where not all components are made autonomic. Whereever this is necessary, it will rely on pre-existing mechanisms for configuration such as CLI "will rely on" can also be seen as an indicator for future work. o When the ACP needs to be extended across interfacess other than L2, the ACP as defined in this document can not autodiscover candidate neighbors automatically. Remove neighbors need to be configured, see Section 8.2. nit: s/Remove/Remote/ Once the ACP is operating, any further configuration for the data- lane can be configured more reliably across the ACP itself because nit: data-plane Section 11 o Every ACP registrar is criticial infrastructure that needs to be hardened against attacks similar to a CA. A malicious registrar nit: as written, this parses as saying that the attacks are similar to a CA, not the amount of hardening needed on the ACP registrar. Adding a comma would probably help. The ACP It is designed to enable automation of current network management and future autonomic peer-to-peer/distributed network s/It // Attacks from impacted ACP nodes against the ACP are more difficult than against the data-plane because of the autoconfiguration of the ACP and the absence of configuration options that could be abused that allow to change/break ACP behavior. This is excluding configuration for workaround in support of non-autonomic components. [...] The ACP acts as a security (and transport) substrate for GRASP inside the ACP such that GRASP is not only protected by attacks from the outside, but also by attacks from compromised inside attackers - by relying not only on hop-by-hop security of ACP secure channels, but adding end-to-end security for those GRASP messages. See Section 6.8.2. This is true, but the system as a whole still has the weakness that the compromised node is able to announce GRASP objectives for arbitrary services and potentially cause legitimate traffic to be directed towards it. The connection would still validate (until the certificate expires or is revoked) and the attacker could return bad data that causes honest nodes to misbehave. revocation and non-renewal of short-lived cdrtificates. In this nit: "certificates" Section A.6 In my opinion, a lot of this could be split out into a separate draft (that need not be published as an RFC) and just a couple paragraphs left here with a pointer to that separate draft. But this is only a Comment-level point, and I do not insist on it. Section A.7 An ACP domain is the set of all ACP nodes using certificates from the same CA using the same domain field. GRASP inside the ACP is run across all transitively connected ACP nodes in a domain. It's not entirely clear to me that we need to insist on a single shared CA; given our discussion of potentially joining two distinct ACT domains into a combined network, it seems that we just need to have all nodes using the same set of trust anchor(s), which could potentially include multiple CAs. (There would of course need to be some out-of-band mechanism to avoid address-assignment collisions, which could be as simple as rsub.) Section A.8 For example, Intent could indicate the desire to build an ACP across all domains that have a common parent domain (without relying on the rsub/routing-subdomain solution defined in this document). For example ACP nodes with domain "example.com", "access.example.com", "core.example.com" and "city.core.example.com" should all establish one single ACP. It is interesting to see this discussion in the context of the text in the previous section about """If different ACP domains are to be created [...] Domains "example.com" and "research.example.com" are separate domains if both are domain elements in the domain information element of certificates.""" Section A.8 There still feels like a lot of speculative things in here; I'd suggest adding a disclaimer/introduction at the top that "Intent is the architecture component [...]. Its applicability for use is quite flexible and freeform, with potential applications including:" Section A.9 Some solutions may already have an auto-addressing scheme, for example derived from existing unique device identifiers (e.g., MAC addresses). In those cases it may not be desirable to assign addresses to devices via the ACP address information field in the way described in this document. The certificate may simply serve to identify the ACP domain, and the address field could be empty/unused. The only fix required in the remaining way the ACP operate is to define another element in the domain certificate for the two peers to decide who is Alice and who is Bob during secure channel building. I think we need to mention this requirement for tiebreaking earlier in the document, when we introduce the possibility of a certificate with ACP address of '0'. Section A.10 nit: the section title uses "futures" as a standalone term synonymous with "future work"; unfortunately, "futures" is already an English word with a quite distinct meaning. Section A.10.7 1. Consider if LLDP should be a recommended functionality for ANI devices to improve diagnostics, and if so, which information elements it should signal (insecure). Includes potentially new information elements. I'd suggest changing the parenthetical to "noting that such information is conveyed in an insecure manner)". 3. The IDevID of BRSKI pledges should be included in the selected insecure diagnostics option. In some environments (not really the current target case of Enterprise networks) the IDevID would be considered privacy-sensitive, which may be worth mentioning again here. Section A.10.8 Ensuring that manaement sessions using invalidated credentials are typo: "management" From nobody Tue Jul 16 16:40:13 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC78D120045; Tue, 16 Jul 2019 16:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wG95neO-gGnm; Tue, 16 Jul 2019 16:40:02 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D821C12002F; Tue, 16 Jul 2019 16:40:01 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6GNdfAm020252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 19:39:44 -0400 Date: Tue, 16 Jul 2019 18:39:41 -0500 From: Benjamin Kaduk To: Toerless Eckert Cc: Eric Rescorla , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, The IESG , anima@ietf.org, Sheng Jiang Message-ID: <20190716233939.GC58520@kduck.mit.edu> References: <153316779818.21822.14156274165395996235.idtracker@ietfa.amsl.com> <20190311153144.74vwtv4a22vmfcuk@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190311153144.74vwtv4a22vmfcuk@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 23:40:11 -0000 Not Eric, but playing that role for a bit... On Mon, Mar 11, 2019 at 04:31:45PM +0100, Toerless Eckert wrote: > Thanks Eric, inline >=20 > This file is: https://github.com/anima-wg/autonomic-control-plane/blob/ma= ster/draft-ietf-anima-autonomic-control-plane/16-eric-rescorla-reply.txt >=20 > The following inline answers to your discuss have been integrated > into -19 of the draft which i just submitted. It also includes the > feedback to the comments by Eric and Ben. I was backlogged, and > after your review of -16 i had first responded to other reviewers > with -16/-17. >=20 > Note that this includes a hopefully more comprehensive section 6.1.3 expl= aining the Trust Anchor details required for the ACP, resulting from the va= riety of discuss of the reviewers on this topic. >=20 > Bens and Erics review where very good and comprehensive but alas > didn't make it easy for me to answer to them as quickly as i would have > wanted to. Unfortunately, i also had to go back and forth between > them, so i couldn't create a separate checkpoint version > showing ONLY changes for each of them. So the following diffs are > hopefully useful: >=20 > -18 to -19: Changes made for Ben and Eric >=20 > http://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-anima-autonomic-control-plane-18.txt&url2=3Dhttps://tools.ietf.org/id/dra= ft-ietf-anima-autonomic-control-plane-19.txt >=20 > Note that this includes a hopefully more comprehensive section 6.1.3 expl= aining the Trust Anchor details required for the ACP, resulting from the va= riety of discuss of the reviewers on this topic. >=20 > -16 to -19: Changes since your last review (includes Alissa Coopers revie= w) >=20 > http://tools.ietf.org//rfcdiff?url2=3Dhttps://tools.ietf.org/id/draft-iet= f-anima-autonomic-control-plane-16.txt&url2=3Dhttps://tools.ietf.org/id/dra= ft-ietf-anima-autonomic-control-plane-19.txt >=20 > Cheers > Toerless >=20 > On Wed, Aug 01, 2018 at 04:56:38PM -0700, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-16: Discuss > >=20 > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-pla= ne/ > >=20 > >=20 > >=20 > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > >=20 > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D9959 > >=20 > >=20 > > I found this document extremely hard to follow due to a large number > > of grammar errors. It really needs a very thorough copy-edit pass, > > which I believe is beyond the RFC-editor's usual process. Ideally, the > > WG would do this. > >=20 > >=20 > > DETAIL > > S 6.1.1. > > > each other. See Section 6.1.2. Acp-domain-name SHOULD be the F= QDN > > > of a DNS domain owned by the operator assigning the certificate. > > > This is a simple method to ensure that the domain is globally un= ique > > > and collision of ACP addresses would therefore only happen due t= o ULA > > > hash collisions. If the operator does not own any FQDN, it shou= ld > > > choose a string (in FQDN format) that intends to be equally uniq= ue. > >=20 > > These rules do not seem to be strong enough. Unless you have disjoint > > trust anchors, there is a potential for cross-domain attac. >=20 > Yes, two independent operators would use their own separate trust anchors. >=20 > If you are are owning the PKI root for multiple independent ACP networks, > you COULD also establish a process by which you validate that there is no > SHA256 hash collision between the different ACP domain names that want > to use your one trust anchor. >=20 > So, i am not sure what your point is. I think there's enough about trust points and trust anchors to be clear that we provide the property Eric was looking for that avoids the cross-domain attack. > > S 6.1.2. > > > See section 4.2.1.6 of [RFC5280] for details on the subjectAltNa= me > > > field. > > > =20 > > > 6.1.2. ACP domain membership check > > > =20 > > > The following points constitute the ACP domain membership check = of a > >=20 > > What is the relationship of these rules to the existing 5280 rules? >=20 > Note that there where already i hope good improvements in this text from = -16 > you reviewed to -18. My read here is that we could address this by "we use the standard PKIX [RFC 5280] certificate validation rules with some additional ACP-specific procedures. In particular: [...]". That is, have a statement about the relationship of this procedure to the 5280 rules (namely, we add to them), to make clear that we are not trying to do some similar but subtly different thing. > The first three bullet points are meant to summarise what we understand t= o be > the standard certificate verification rules for another entity (Bob). Use > ACP trust anchor and some proof of posession mechanism for the private key > (as in e.g.: TLS), verify Bobs cert is in its lifetime.=20 >=20 > It is not clear to me if RFC5280 is normative for this as i could not find > a single section i could point to as a reference. I welcome suggestions > to shorten those rules by referring to prior established rules for the > same. This text was based on suggestions from the BRSKI authors who are m= ore > experts on PKI. >=20 > Bullet item four mandates support for CRL / OCSP if used in the certifica= te. > Likewise: Better text welcome. >=20 > The fifts bullet item is the only new requirement. The ACP information > field must be present, syntactically correct and have the same acp-domain= -name > field as the local node performing the ACP domain membership check. >=20 > > S 6.1.2. > > > =20 > > > o The peer has proved ownership of the private key associated w= ith > > > the certifictes public key. > > > =20 > > > o The peer's certificate is signed by one of the trust anchors > > > associated with the ACP domain certificate. > >=20 > > So you don't allow chaining? It seems later that you say you do, but > > this language prohibits it. >=20 > No, that was an oversight. Changed second bullet to: >=20 > The peer's certificate passes certificate path validation as defined in [= RFC5280] against one of the Trust Anchors associated with the ACP nodes ACP= domain certificate (see below) >=20 > Better text suggestion welcome if this is correct. >=20 > > S 6.1.3.1. > > > The objective value "SRV.est" indicates that the objective is an > > > [RFC7030] compliant EST server because "est" is an [RFC6335] > > > registered service name for [RFC7030]. Future backward compatib= le > > > extensions/alternatives to [RFC7030] may be indicated through > > > objective-value. Future non-backward compatible certificate ren= ewal > > > options must use a different objective-name. > >=20 > > EST runs over HTTPS. What is the certificate that the server presents? >=20 > I could add text like: >=20 > The EST server MUST present a certificate that > is passing ACP domain membership check () in = its HTTPS=20 > () connection setup. As some background, in general, whenever we use HTTPS (or even just TLS), the client needs to have some procedure for how to verify that the server is the entity the client is attempting to talk to. This is almost always certificate validation, but in addition to ensuring that the signatures chain up to a trusted root, the client needs to ensure that the entity that got certified is the (usually named) entity it wants to talk to. So, we might talk about validating that the cert has an RFC 6125 DNS-ID or SRV-ID that matches the initial name that the client sent into DNS, if we were going to use the web PKI. Here, we don't necessarily have or want the web PKI since we can have ACP domain certificates as well. So with my current understanding of the intent (sic) behind the ACP, you do need to include text with this sort of membership check, and probably also want a "the client SHOULD require that the server's certificate include a (as-of-yet, site-specific) X.509 extension to indicate that it is authorized to function as an EST server". (Actually I thought there was something very similar that is already defined and was mentioned in BRSKI, but I'm failing to remember the right search term to find it.) > But i am actually not sure this is required, so i would rather like to do= it > only when we understand it is. The way i understand it, there really does > not need to be transport layer security for certificate renewal because > the client can verify the certificate on its own merit. AFAIK, > draft-ietf-acme-star leverages that for example to provide certs from=20 > arbitrary caches. >=20 > The situation may be different for BRSKI, and likely the EST server can a= lso > be the BRSKI server, but that would still make it better to describe > rewuirements against the server cert in BRSKI rather than in ACP if it > doesn't matter in the EST renewal case.=20 >=20 > > S 6.4. > > > information in the ACP Adjacency table. > > > =20 > > > The ACP is by default established exclusively between nodes in t= he > > > same domain. This includes all routing subdomains. Appendix A.7 > > > explains how ACP connections across multiple routing subdomains = are > > > special. > >=20 > > I must be missing something, but how do you know what the routing > > domain is of an ACP node? I don't see it in the message above. Is it > > in some common header? >=20 > The routing subdomain is indicated via the ACP domain information field > in the certificate, but it is ignored during step 4 of the ACP domain mem= bership > check hence resulting in above text that the ACP is built across all > routing-subdomains. It only serves to assign different address prefixes > within the same ACP network right now. >=20 > > S 6.5. > > > =20 > > > o Once the first secure channel protocol succeeds, the two peers > > > know each other's certificates because they must be used by a= ll > > > secure channel protocols for mutual authentication. The node= with > > > the lower Node-ID in the ACP address becomes Bob, the one wit= h the > > > higher Node-ID in the certificate Alice. > >=20 > > A ladder diagram would really help me here, because I'm confused about > > the order of events. >=20 > Can not figure out how to RFC-ASCII'fy a ladder diagram with the two > parallel connection setups, so i rather added the following more explicit > list of steps as a picture after the example. Hope this suffices to > answer your request. >=20 > | [1] Node 1 sends GRASP AN_ACP message to announce itself > |=20 > | [2] Node 2 sends GRASP AN_ACP message to announce itself > |=20 > | [3] Node 2 receives [1] from Node 1 > |=20 > | [4:C1] Because of [3], Node 2 starts as initiator on its > | preferred secure channel protocol towards Node 1. > | Connection C1. > |=20 > | [5] Node 1 receives [2] from Node 2 > |=20 > | [6:C2] Because of [5], Node 1 starts as initiator on its > | preferred secure channel protocol towards Node 2. > | Connection C2. > |=20 > | [7:C1] Node1 and Node2 have authenticated each others > | certificate on connection C1 as valid ACP peers. > |=20 > | [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, > | therefore Node 1 considers itself Bob and Node 2 Alice > | on connection C1. Connection setup C1 is completed. > |=20 > | [9] Node 1 (Bob)) refrains from attempting any further secure > | channel connections to Node 2 (Alice) as learned from [2] > | because it knows from [8:C1] that it is Bob relative > | to Node 1. > |=20 > | [10:C2] Node1 and Node2 have authenticated each others > | certificate on connection C2 (like [7:C1]). > |=20 > | [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, > | therefore Node 1 considers itself Bob and Node 2 Alice > | on connection C1, but they also identify that C2 is to the > | same mutual peer as their C1, so this has no further impact. > |=20 > | [12:C2] Node 1 (Alice) closes C1. Because of [8:C1], Node 2 (Bob) > | expected this. > |=20 > | [13] Node 1 (Alice) and Node 2 (Bob) start data transfer across > | C2, which makes it become a secure channel for the ACP. > |=20 > > As I understand it, Alice and Bob are both flooding their AN_ACP > > objectives. So, Alice sees Bob's and starts trying to connect to Bob. > > But Bob may not have Alice's objective, right? So, in the case you > > describe below, she just has to wait for it before she can try the > > remaining security protocols? >=20 > A node can initiate and complete in parallel any number of secure > channel protocol to a candidate peer (from which it has received > a AN_ACP GRASP objective). But as soon as one of those connection > succeeds and the node know it is "Bob" on the connection (because > of the comparison with the peers certificates ACP domain information fiel= d), > it will stop trying new connections to that peers IPv6 link-local address, > and its Alice's choice to figure out which of the potentially > parallel established connections to close and which to continue. >=20 > Aka: The logic is intended to be as simple as possible and secure. > The Alice/Bob self selection is secure because it is based on what > is learned from successfull secure channel setup. >=20 > > I note that you have no downgrade defense on the meta-negotiation > > between the protocols, so an attacker could potentially force you down > > to the weakest joint protocol. Why did you not provide a defense here? >=20 > Remember that the goal of this process is the negotiation to select > one of potentially multiple completely disjoint secure channel > protocols. Such as DTLS vs. IPsec. And attempting to avoid he ned > to a network wide MTI protocol because we only use these protocols > for peer-to-peer and not every two nodes in the network need to be able to > directly peer with each other (you won't connect an IoT gateway to > an Internet backbone core-router). >=20 > One approach we thought of to allow negotiation of "the best" crypto > mutually supported would be to have a two-stage negotiation, e.g.: > first build some TLS connection and negotiate the next-stage, IPsec or DT= LS. > But that would make thast first stage a network-wide MTI and run into > the risk that that protocols crypto becomes the weakest link. I actually > had that option in an earlier version of the draft and the WG and IETF > reviewers didn't like this double complexity, so it was removed. >=20 > If i have a man-in-the-middle, i also don't think eve such a two-stage > would work. I could negotiate what i think is the better crypto option > (let's say DTLS) all day long, but if the MiTM simply filters all DTLS > and only lets through IPsec, what can i do ? Talking things through... In the MITM case such as this, the idea would be to just drop all connection attempts other than the "weakest link" so that Alice and Bob both think that each other don't support the strong mechanisms. If the attacker can realtime break the weakest link, then they can inject themselves into the secure connection; if either Alice or Bob (or both) were unwilling to support the weakest link, then the attacker could only block traffic but not MITM the secure connection. Generally we can prevent this by requiring Alice and Bob to verify what connection types they respectively support, preferrably by directly using this information as input to a key schedule (so it *has* to get verified) but a separate comparison will still work if actually implemented. Then the only other check is that the negotiated connection is the strongest that's mutually supported. Since we're doing Alice's preference, Alice would need to make the check (and Bob is reliant on Alice to detect such MITM downgrade attacks). For TLS, it's fairly common to stuff this sort of information into a TLS Extension and have the appropriate party check what the other side got, but I don't remember a similar mechanism for IKEv2. (Maybe transform attributes, but I'm not sure.) Trying to make the check happen after the secure connection is established doesn't work, because by then the attacker is already in place with the MITM. I guess in the case the attacker doesn't have a full break, the post-facto check would still let you detect the attacker's presence. It does seem like we should be able to do at least a little better than "just trust everybody to disable bad connection types when they are known to be broken". > > S 6.7.1.1. > > > To run ACP via IPsec natively, no further IANA assignments/ > > > definitions are required. An ACP node that is supporting native > > > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, loca= l and > > > peer link-local IPv6 addresses used for encapsulation. It MUST = then > > > support ESP with AES256 for encryption and SHA256 hash and MUST = NOT > > > permit weaker crypto options. > >=20 > > This is not sufficient to guarantee interop. Also, this is an odd > > cipher suite chioice. > >=20 > > Why are you requiring AES-256 rather than AES-128? >=20 > In all the implementations i was involved in we did not find hardware > that did not support AES-256, but there where platforms that could > not go higher, so this looked like the highest crypto safe length > to support common hardware crypto. >=20 > > Why aren't you requiring AES-GCM? >=20 > Thanks. The need to specify this level of detail was not raised in before. > I have replaces AES256 with AES-256-GCM (rfc4106). >=20 > > Why aren't you requiring specific key establishment methods (e.g., > > ECDHE with P-256...) >=20 > Added.=20 >=20 > If the text is still insufficient in your opinion, i would welcome sugges= ted > text that you consider to be a good recommendation, or at least the > set of parameters that we missed to specifiy.=20 >=20 > > S 6.7.2. > > > =20 > > > To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP > > > port is used that is announced as a parameter in the GRASP AN_ACP > > > objective to candidate neighbors. All ACP nodes supporting DTLS= as a > > > secure channel protocol MUST support AES256 encryption and MUST = NOT > > > permit weaker crypto options. > >=20 > > This is not sufficiently specific to guarantee interoperability. Which > > cipher suites? Also, why are you requiring AES-256 and not AES-128? >=20 > Removed AES-256 notion. >=20 > The reason for AES-256 was to be aligned with the IPsec requirements, > but of course, our expectation is that DTLS would be a SW implementation,= so > this is not necessarily a good choice. Although i think the lowest common > denominator for DTLS is 128 ? >=20 > In any case, i changed the text to be equivalent to RFC8310 section 9. Th= is > is the RFC thast you suggested me to leverge some time ago in email: >=20 > | All ACP nodes supporting DTLS as a secure channel protocol MUST > | adhere to the DTLS implementation recommendations and security > | considerations of except with respect > | to the DTLS version. ACP nodes supporting DTLS MUST implement only > | DTLS 1.2 or later. For example, implementing DTLS-1.3 > | () is also an option. >=20 > The other MUST/SHOULD from RFC8310 section 9 did not seem to be relevant= =20 > for our purposes. >=20 > > S 6.7.3. > > > =20 > > > A baseline ACP node MUST support IPsec natively and MAY support = IPsec > > > via GRE. A constrained ACP node that can not support IPsec MUST > > > support DTLS. An ACP node connecting an area of constrained ACP > > > nodes with an area of baseline ACP nodes MUST therefore support = IPsec > > > and DTLS and supports threefore the baseline and constrained pro= file. > >=20 > > These MTIs do not provide interop between constrained and baseline > > nodes, because a baseline node might do IPsec and the constrained node > > DTLS. >=20 > Yes. 6.5. Channel Selection: >=20 > I improved the text of this paragraph also for this review (example > was not as strong in before): >=20 > Not all type of ACP nodes can or need to connect directly to each othe= r or are able to support or prefer all possible secure channel mechanisms. = For example, code space limited IoT devices may only support DTLS because = that code exists already on them for end-to-end security, but high-end core= routers may not want to support DTLS because they can perform IPsec in acc= elerated hardware but would need to support DTLS in an underpowered CPU for= warding path shared with critical control plane operations. This is not a d= eployment issue for a single ACP across these type of nodes as long as ther= e are also appropriate gateway ACP nodes that support sufficiently many sec= ure channel mechanisms to allow interconnecting areas of ACP nodes with a m= ore constrained set of secure channel protocols. On the edge between IoT ar= eas and high-end core networks, general-purpose routers that act as those g= ateways and that can support a variety of secure channel protocols is the n= orm already. >=20 > Aka: there is no MTI and no need for an MTI because we don't need end-to-= end > security for ACP secure channels but only hop-by-hop, and we define > different profiles in "ACP Secure Channel Requirements" (6.7.3) >=20 > > S 6.10.2. > > > hash of the routing subdomain SHOULD NOT be assumed by any ACP > > > node during normal operations. The hash function is only exe= cuted > > > during the creation of the certificate. If BRSKI is used the= n the > > > BRSKI registrar will create the domain information field in > > > response to the EST Certificate Signing Request (CSR) Attribu= te > > > Request message by the pledge. > >=20 > > you need to lay out the security assumptions here. It's not difficult > > to create a new domain with the same 40bit hash. >=20 > If you don't attempt to do this, the chance for this to happen is a lot > lower than winning the lottery, so it would have to be a suicidal operato= r. >=20 > Prepended before that paragraph: >=20 > | When creating a new routing-subdomain for an existing autonomic network, > | it MUST be ensured, that rsub is selected so the resulting hash of the > | routing-subdomain does not collide with the hash of any pre-existing > | routing-subdomains of the autonomic network. This ensures that ACP > | addresses created by registrars for different routing subdomains do not > | collide with each others. >=20 > And appended after that paragraph: >=20 > | Establishing connectivity between different autonomic networks > | (different acp-domain-name) is outside the scope of this specification. > | If it is being done through future extensions, then the rsub of all > | routing-subdomains across those autonomic networks need to be selected > | so their hashes do not collide. For example a large cooperation with its > | own private Trust Anchor may want to create different autonomic networks > | that initially should not be able to connect but where the option to do > | so should be kept open. When taking this future possibility into accoun= t, > | it is easy to always select rsub so that no collisions happen. >=20 > > If you have a private > > CA, this probably isn't an issue, but if you are sharing a public CA, > > it would allow me to produce a domain with other people's addresses. >=20 > The following is the pre-existing text from 6.1.3 intended > to cover this: >=20 > Trust Points for ACP domain certificates must be trusted to sign > certificates with valid ACP domain information fields only for > trusted ACP registrars of that domain. This can be achieved by using > Trust Anchors private to the owner of the ACP domain or potentially > through appropriate contractual agreements between the involved > parties. Public CA without such obligations and guarantees can not > be used. >=20 > A single owner can operate multiple independent ACP domains from the > same set of private trust anchors (CAs). When the ACP Registrars are > trusted not to permit certificates with incorrect ACP information > fields to be signed. ... >=20 > Let me know if you think more elaboration is required. >=20 > > S 8.1.1. > > > configured to be put into the ACP VRF. The ACP is then accessib= le to > > > other (NOC) systems on such an interface without those systems h= aving > > > to support any ACP discovery or ACP channel setup. This is also > > > called "native" access to the ACP because to those (NOC) systems= the > > > interface looks like a normal network interface (without any > > > encryption/novel-signaling). > >=20 > > This seems pretty unclear. Is the idea that you connect natively to > > the ACP Connect node and then it forwards your packets over the ACP? >=20 > Yes. No secure channel used, needs to be explicitly configured. Expects > appropriate physical security. Limited to one L3 subnet hop, so typically > an ACP edge node co-located via an ethernet cable to e.g.: an SDN > controller in a room with physcial access control. >=20 > > Does that mean they need to be GRASP or whatever? I think that's what > > you are saying below. >=20 > ACP has two type of GRASP instances, ACP grasp and secure channel > autoconfig DULL GRASP. >=20 > ACP GRASP runs over those interfaces like it runs over ACP interfaces > constructed across secure channels. But there is no DULL GRASP neighbor > discovery, as thats only needed to construct ACP secure channels. >=20 > Not sure how to improve text to make it easier readable. Suggestions welc= ome. >=20 > > S 8.1.5. > > > interface is physically protected from attacks and that the conn= ected > > > Software or NMS Hosts are equally trusted as that on other ACP n= odes. > > > ACP edge nodes SHOULD have options to filter GRASP messages in a= nd > > > out of ACP connect interfaces (permit/deny) and MAY have more fi= ne- > > > grained filtering (e.g., based on IPv6 address of originator or > > > objective). > >=20 > > Given that this is an important security requirement, it seems like it > > should be a normative requirement that it be filtered. >=20 > This is not a security requirement but an administrative policy filtering > requirement. You assume the servers you allow to connect to an ACP connect > network to be trusted. They may just not provide flexible filtering of > the services they offer so the network device can add that through above > mentioned policy filtering of the GRASP announcements. "this is a trusted network" does tend to get skeptical responses from the IETF security community, it is true. -Ben > > S 9.1. > > > same trust anchor, a re-merge will be smooth. > > > =20 > > > Merging two networks with different trust anchors requires the t= rust > > > anchors to mutually trust each other (for example, by cross-sign= ing). > > > As long as the domain names are different, the addressing will n= ot > > > overlap (see Section 6.10). > >=20 > > Why does it require the *trust anchors* to trust each other? Can't the > > endpoints just have the union of the trust anchors. > >=20 > > This is way underspecified for actual implementation. >=20 > Yepp. goes back to version 6 of the doc, before i started to refine the t= ext > from a more declarative to a more implementable level of detail. Overlook= ed > so far by me when i started write down all the PKI details. Replaced with: >=20 > | Merging two networks with different trust anchors requires the ACP nodes > | to trust the union of Trust Anchors. As long as the routing-subdomain > | hashes are different, the addressing will not overlap (see ). > | Note that the complete mechanisms to merge networks is out of scope of > | this specification. >=20 > Btw: this is already the start of informative text again (post normative). >=20 > > S 10.2.1. > > > registrar can rely on the ACP and use Proxies to reach the candi= date > > > ACP node, therefore allowing minimum pre-existing (auto-)configu= red > > > network services on the candidate ACP node. BRSKI defines the B= RSKI > > > proxy, a design that can be adopted for various protocols that > > > Pledges/candidate ACP nodes could want to use, for example BRSKI= over > > > CoAP (Constrained Application Protocol), or proxying of Netconf. > >=20 > > I am finding it very difficult to work out the security properties of > > this mechanism and the security considerations do not help. What can a > > malicious registrar do? For that matter, you say "uncoordinated", so > > does that mean anyone in the ACP can just decide to be a registrar? >=20 > The uncoordinated refers to the fact that each ACP registrar creates the > ACP domain informatin field, thereby assigning an ACP address to a pledge > for which it enrolls the certificate. The ACP addressing schemes are desi= gned > so that each ACP registrar can do this without having to coordinate with > other ACP registrars or another central entity. Therefore the only central > entity required is some hopefully pre-existing, PKI CA/sub-CA infra that > doesn't have to know about ACP specifics at all. >=20 > This section is already informal, and in a presentation i tried to show > how even a person could be a registrar, aka: no formal need of ACP for > it to be software. Hence the very protocol unspecific definition. >=20 > I added the following paragraph to the end of 6.10.7(.0) which is the nor= mative > part for ACP registrar to hopefully answer the security question sufficie= ntly: >=20 > | ACP registrars are PKI registration authorities (RA) enhanced with > | the handling of the ACP domain certificate specific fields. They > | request certificates for ACP nodes from a Certificate Authority > | through any appropriate mechanism (out of scope in this document, > | but required to be BRSKI for ANI registrars). Only nodes that > | are trusted to be compliant with the requirements against registrar > | described in this section must be given the necessary credentials > | to perform this RA function, such as credentials for the BRSKI > | connection to the CA for ANI registrars. >=20 > And to Security considerations: >=20 > | Every ACP registrar is criticial infrastructure that needs to be harden= ed against attacks similar to a CA. A malicious registrar can enroll enemy = plegdes to an ACP network or break ACP routing by duplicate ACP address ass= ignment to pledges via their ACP domain certificates. >=20 > > S 11. > > > =20 > > > 11. Security Considerations > > > =20 > > > An ACP is self-protecting and there is no need to apply configur= ation > > > to make it secure. Its security therefore does not depend on > > > configuration. > >=20 > > This is not true. You need to configure the trust anchor and the > > domain name. >=20 > Changed to: >=20 > | After seeding an ACP by configuring at least one ACP registrar with rou= ting-subdomain and a CA, an ACP is self-protecting and there is no need to = apply configuration to make it secure (typically the ACP Registrar doubles = as EST server for certificate renewal). >=20 > Originally the idea was to consider ACP registrar/EST server part of the = BRSKI effort in ANIMA, hence the simpler original statement. But it turned = out to be illogical to describe all the ACP specifics of ACP registrars in = BRSKI if we wanted to make it reuseable without ACP. >=20 > > S 11. > > > all products. > > > =20 > > > There is no prevention of source-address spoofing inside the ACP. > > > This implies that if an attacker gains access to the ACP, it can > > > spoof all addresses inside the ACP and fake messages from any ot= her > > > node. > >=20 > > You need to be clear that the security is just group security and that > > any compromised ACP node compromises the entire system. >=20 > Right. Ben had more points about the insufficiency of the security consid= erations > text, so i expanded the point here with several paragraphs. >=20 > A bit too long to paste here. Starts and ends with the follwing, easy to = see in rfcdiff: >=20 > | The ACP It is designed to enable automation of current network manageme= nt and future autonomic peer-peer/distributed network automation. ... > .... > | Higher layer service built using ACP domain certificates should not sol= ely rely on undifferentiated group security.... >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > S 1. > > > possibilities that where considered not to be appropriate for > > > standardization in this document but were considered important to > > > document. > > > =20 > > > The ACP provides secure IPv6 connectivity, therefore it can not = only > > > be used as the secure connectivity for self-management as requir= ed > >=20 > > Nit: this would be clearer as "can be used not only" >=20 > Thanks. >=20 > > S 2. > > > equally be used in simple ANI networks (with no other Autonom= ic > > > Functions) or completely by itself. > > > =20 > > > ACP address: An IPv6 address assigned to the ACP node. It is s= tored > > > in the domain information field of the ->"ACP domain certific= ate" > > > (). > >=20 > > Something wrong here. >=20 > See note on top of Section 2 introduced in -17, its about the XML > xref's. If RFC-editor can't help, we'll fix manually (reference containin= g () ). >=20 > > S 2. > > > =20 > > > domain information (field): An rfc822Name information element (= e.g., > > > field) in the domain certificate in which the ACP relevant > > > information is encoded: the domain name and the ACP address. > > > =20 > > > ACP Loopback interface: The Loopback interface in the ACP VRF t= hat > >=20 > > Please expand VRF on first use. >=20 > Done (pre -19). >=20 > > S 2. > > > routing and forwarding in the node other than the ACP VRF. I= n a > > > simple ACP or ANI node, the Data-Plane is typically provision= ed > > > non-autonomic, for example manually (including across the ACP= ) or > > > via SDN controllers. In a fully Autonomic Network node, the = Data- > > > Plane is managed autonomically via Autonomic Functions and In= tent. > > > Note that other (non-ANIMA) RFC use the Data-Plane to refer to > >=20 > > Nit: RFCs >=20 > Done. >=20 > > S 4. > > > protocols of the ANI. Clients of the ACP MUST NOT be tie= d to > > > a particular application or transport protocol. > > > =20 > > > ACP5: The ACP MUST provide security: Messages coming through th= e ACP > > > MUST be authenticated to be from a trusted node, and SHOU= LD > > > (very strong SHOULD) be encrypted. > >=20 > > Why isn't this a MUST? Once you have done the key setup, the > > encryption is very cheap. >=20 > This is the section describing the input requirements into the specificat= ion > of the ACP (charter didn't allow a separate requirements document). It is > not the actual normative requirement for the ACP described in section 6 = (there > it is a MUST for encryption). >=20 > Various reasons for customers not wanting encryption: regulation (e.g.: f= inance networks > auditing), inability to support HW enryption at speeds/cost-point needed = (e.g.: > data-center). Hop-by-hop encryption to protect infrastructure is somethi= ng completely > different from end-to-end encryption wrt. cost. We don't even have a good= idea > how much performance for transit traffic we need across ACP nodes. if yo = want to > build across the ACP more intelligent network automation you may want to = pull a lot > of telemetry across it. >=20 > Alas, we had to conclude that for the start it would be too much work to > include all necessary work to make those requirements work, so this base > ACP specification has the MUST in the normative part. Solutions for diffe= rent > markets for whom this is not appropriate would be different anyhow. Finan= ce > regulations could result in networks effectively uses message integrity b= ut > not encryption, whereas DC might use a lower security model..=20 >=20 > > S 4. > > > between nodes, but only GRASP connectivity. Nevertheless, becau= se > > > ACP also intends to support non-AN networks, it it is crucial to > > > support IPv6 layer connectivity across the ACP to support any > > > transport and application layer protocols. > > > =20 > > > Th eACP operates hop-by-hop, because this interaction can be bui= lt on > >=20 > > Nit: The ACP >=20 > Done. >=20 > > S 6.1.1. > > > hash collisions. If the operator does not own any FQDN, it shou= ld > > > choose a string (in FQDN format) that intends to be equally uniq= ue. > > > =20 > > > "routing-subdomain" is the autonomic subdomain that is used to > > > calculate the hash for the ULA Global ID of the ACP address of t= he > > > node. "rsub" is optional; its syntax is defined in this documen= t, > >=20 > > This section about the hash isn't clear without referencing some > > future section. >=20 > Added reference to section defining the use of ULA (addressing section). >=20 > > S 6.1.1. > > > In this specification, the "acp-address" field is REQUIRED, but > > > future variations (see Appendix A.8) may use local information to > > > derive the ACP address. In this case, "acp-address" could be em= pty. > > > Such a variation would be indicated by an appropriate "extension= ". > > > If "acp-address" is empty, and "rsub" is empty too, the "local-p= art" > > > will have the format "rfcSELF + + extension(s)". The two plus > >=20 > > Are these spaces part of local-part? They appear to be forbidden by > > the ABNF >=20 > No, spaces where just meant for visualization, but obviously confusing. R= emoved spaces. >=20 > > S 6.1.1. > > > The subjectAltName / rfc822Name encoding of the ACP domain name = and > > > ACP address is used for the following reasons: > > > =20 > > > o It should be possible to share the LDevID with other uses bes= ide > > > the ACP. Therefore, the information element required for the= ACP > > > should be encoded so that it minimizes the possibility of cre= ating > >=20 > > Is this really not normative? >=20 > No. We can not use the ACP spec to force any non-ACP function on a router= to > share the ACP certificate. We can just design the ACP certificate content= so > that it would not conflict with the content required for other uses and h= ope that > this eliminates an important limiter to minimizing the number of redundant > certificates a router needs to maintain across various functions. >=20 > (If there are good reasons for different certs, they are not "redundant" = ;-) >=20 > > S 6.1.3.5. > > > protocols used by the ACP registrars. > > > =20 > > > Please refer to Section 6.10.7 for explanations about ACP regist= rars > > > and vouchers as used in the following text. > > > =20 > > > When BRSKI is used (aka: on ACP nodes that are ANI nodes), the r= e- > >=20 > > I think you mean "i.e.", not "aka". >=20 > Thanks. >=20 > > S 6.1.3.5. > > > certificate or the IDevID, the re-enrolling candidate ACP node S= HOULD > > > authenticate the BRSKI registrar during TLS connection setup bas= ed on > > > its existing trust anchor/certificate chain information associat= ed > > > with its old ACP certificate. The re-enrolling candidate ACP no= de > > > SHOULD only request a voucher from the BRSKI registrar when this > > > authentication fails during TLS connection setup. > >=20 > > This is all pretty hard to understand without having read BRSKI >=20 > Updated lead in text to say: >=20 > Please refer to and > for explanations about ACP registrars and vouchers as used in the followi= ng text. > When ACP is intended to be used without BRSKI, the details about BRSKI and > vouchers in the following text can be skipped. >=20 > > S 6.1.3.6. > > > =20 > > > An ACP domain certificate is called failing in this document, if= /when > > > the ACP node can determine that it was revoked (or explicitly not > > > renewed), or in the absence of such explicit local diagnostics, = when > > > the ACP node fails to connect to other ACP nodes in the same ACP > > > domain using its ACP certificate. For connection failures to > >=20 > > I don't understand the thing on the other side of this "or". I'm > > supposed to conclude based on some remote diagnostic that my cert is > > bad> >=20 > This is primarily a definition, independent of who makes the assertion. > Could be the node itself, could be a registrar >=20 > Depends on capabilities of secure channel protocols, the node may be able > to self-diagnose. For example if the secure channel protocol allows to > authenticate the peer as a valid domain peer but the connection setup > still fails because the peer does not accout our certificate. >=20 > Isn't there also in some secure channel mechanism a way to receive revoca= tion > lists ? That would be an explicit way to learn our certificate has failed > (revocation is a failure). >=20 > > S 6.1.3.6. > > > or any of its signing certificates could have been revoked or may > > > have expired, but the ACP node can not self-diagnose this condit= ion > > > directly. Revocation information or clock synchronization may o= nly > > > be available across the ACP, but the ACP node can not build ACP > > > secure channels because ACP peers reject the ACP node's domain > > > certificate. > >=20 > > Is the idea here that I'm supposed to inspect the TLS alerts? >=20 > Secure channels considered right now are IPsec and DTLS. I don't even know > what TLS alerts provide, but if they are supported via DTLS and provide > useful diagnosis for this condition, it might be useful to mention. > Any pointer to what a TLS alert can tell me ? >=20 > > S 6.3. > > > dependencies, including ACP. Please ensure that references to I- > > > D.ietf-anima-grasp that include section number references (throu= ghout > > > this document) will be updated in case any last-minute changes in > > > GRASP would make those section references change. > > > =20 > > > DULL GRASP is a limited subset of GRASP intended to operate acro= ss an > >=20 > > Please expand DULL >=20 > Done. >=20 > > S 6.4. > > > =20 > > > o ACP connections across domains with different Certificate > > > Authorities (CA) could establish a common ACP by installing t= he > > > alternate domains' CA into the trusted anchor store. This is= an > > > executive management action that could easily be accomplished > > > through the control channel created by the ACP. > >=20 > > How would you know if other domains had a given CA? >=20 > This future intent stuff was moved into A.8 by Alissa's review. Says for= example: >=20 > If each domain has its own source of Intent, then the Intent would sim= ply have to > allow adding the peer domains trust anchors (CA) and domain names to the = ACP domain membership check > () so that nodes from those other domains are= accepted as ACP peers. >=20 > Aka: inject the other domains info into network wide intent. Which we hav= en't defined. Hence A.8. > (not really difficult to do though, we have a draft for Intent distributi= on). >=20 > >=20 > > S 6.5. > > > version 1.2", see [RFC6347]) because that code exists already on= them > > > for end-to-end security, but low-end in-ceiling L2 switches may = only > > > want to support Media Access Control Security (MacSec, see 802.1= AE > > > ([MACSEC]) because that is also supported in their chips. Only a > > > flexible gateway device may need to support both of these mechan= isms > > > and potentially more. > >=20 > > Why are you mentioning MACSEC? Your negotiation syntax doesn't support > > it. >=20 > Added: >=20 > Note that MacSec is not required by any profiles of the ACP in this speci= fication but just mentioned as a likely next interesting secure channel pro= tocol. >=20 > (MacSec might be the only encryption we could get into data centers ;-) >=20 > > S 6.5. > > > version 2", see [RFC7296]. It is now up to Alice to decide how = to > > > proceed. Even if the IPsec connection from Bob succeeded, Alice > > > might prefer another secure protocol over IPsec (e.g., FOOBAR), = and > > > try to set that up with Bob. If that preference of Alice succee= ds, > > > she would close the IPsec connection. If no better protocol att= empt > > > succeeds, she would keep the IPsec connection. > >=20 > > When would you get partial failrues? >=20 > The text does not mention partial failures. Can you please rephrase your = question ? >=20 > > S 6.7.1.2. > > > support IPsec transport mode with next protocol equal to GRE (47) > > > followed by the offer for native IPsec as described above (becau= se > > > that option is mandatory to support). > > > =20 > > > If IKEv2 initiator and responder support GRE, it will be selecte= d. > > > The version of GRE to be used must the according to [RFC7676]. > >=20 > > See above interop comments. >=20 > See above answer to above interop comment. >=20 > > S 6.7.3. > > > An ACP secure channel MUST immediately be terminated when the > > > lifetime of any certificate in the chain used to authenticate the > > > neighbor expires or becomes revoked. Note that this is not stan= dard > > > behavior in secure channel protocols such as IPsec because the > > > certificate authentication only influences the setup of the secu= re > > > channel in these protocols. > >=20 > > How does this interact with reissue? I am supposed to reconnect? >=20 > Yes. I have actually not managed to insight into whether we can maintain > an IPsec connection without interrupting its data-plane when one of > the peers has to renew its certificate (is that what you call reissue ?). >=20 > I hope this is possible, otherwise we have to reconsider how strong we wa= nt to > make the termination of secure channels. If i wanted to build an ACP > with short-term certificates valid for 30 minutes and effectively > get renewed every 20 minutes, i do not want to have interruption of ACP s= ecure > channels every 20 minutes. >=20 > >=20 > > S 6.8.2. > > > Figure 7: ACP as security and transport substrate for GRASP > > > =20 > > > GRASP unicast messages inside the ACP always use the ACP address. > > > Link-local ACP addresses must not be used inside objectives. GR= ASP > > > unicast messages inside the ACP are transported via TLS 1.2 > > > ([RFC5246]) connections with AES256 encryption and SHA256. Mutu= al > >=20 > > Again, why AES256/SHA256? >=20 > Longest key length we now to be widely supported in HW. Changed to AES-25= 6-GCM. >=20 > Any better recommendations welcome. >=20 > > S 6.8.2.1. > > > original objective in GRASP when it is a MITM and act as an > > > application level proxy. This of course requires that the > > > compromised ACP node understand the semantics of the GRASP > > > negotiation to an extent that allows it to proxy it without being > > > detected, but in an ACP environment this is quite likely public > > > knowledge or even standardized. > >=20 > > Just to make sure I'm clear: you would know you were talking to A and > > not B (because the certificate) so that would be of some use, right? >=20 > TLS avoids easy MITM active attacks. It does not eliminate complex > MITM acive attacks if your communication does not have a specific known > identity of the peer (such as a domain name where the certificate validat= es > the domain). Or another mean to distinguish it from an imposter. >=20 > The original autonomic networking goal is that any node could > start any type of service, and the client just connects to a node offering > the service. In such an application environment, an onpath compromised > node could not only take over the role of a service provider but also > do MITM between two other nodes. >=20 > My brain hurts trying to figure out an example where the compromised node > would actually create more havoc by being such a MITM instead of just > being an imposter of a service provided or service consumed ;-) >=20 > Luckily these are questions to the next layer of services on top of te > ACP. Here we just wanted to describe what the ACP (including ACP GRASP) > infra can and what it can not provide. >=20 > > S 6.8.2.1. > > > encryption. Future work optimizations could avoid this but it is > > > unclear how beneficial/feasible this is: > > > =20 > > > o The security considerations for GRASP change against attacks = =66rom > > > non-ACP (e.g., "outside") nodes: TLS is subject to reset atta= cks > > > while secure channel protocols may be not (e.g., IPsec is not= ). > >=20 > > I don't think the distinction here is between "secure channel" and > > "TLS"; usually I would call TLS a secure channel protocol. Maybe > > "secure transport" or "L3"? > >=20 > > Note that QUIC would not have this problem. >=20 > How about TLS 1.3 ? >=20 > > S 6.12.5. > > > the same. The difference happens when Bob and Carol receive the= ir > > > packet. If they use ACP point-to-point virtual interfaces, their > > > GRASP instance would forward the packet from Alice to each other= as > > > part of the GRASP flooding procedure. These packets are unneces= sary > > > and would be discarded by GRASP on receipt as duplicates (by use= of > > > the GRASP Session ID). If Bob and Charly's ACP would emulate a > >=20 > > Charly? Do you mean Carol? >=20 > Fixed by Bens review. >=20 > > S 7.1. > > > create ACP point-to-point virtual interfaces for these secure > > > channels. > > > =20 > > > 7. ACP support on L2 switches/ports (Normative) > > > =20 > > > 7.1. Why > >=20 > > This hed could be better. >=20 > Changed to: Why (Benefits of ACP on L2 switches) >=20 > > S 8.1.1. > > > explicit configuration. To support connections to adjacent non-= ACP > > > nodes, an ACP node must support "ACP connect" (sometimes also ca= lled > > > "autonomic connect"): > > > =20 > > > "ACP connect" is a function on an autonomic node that is called = an > > > "ACP edge node". With "ACP connect", interfaces on the node can= be > >=20 > > This sentence is confusing. Perhaps first explain what an edge node > > is and then say ACP connect is a function of it. >=20 > Changed to: >=20 > "ACP connect" is an interfacel level configured workaround for connection= of trusted non-ACP nodes to the ACP. The ACP node on which ACP connect is = configured is called an "ACP edge node". With ACP connect, the ACP is acces= sible from those non-ACP nodes (such as NOC systems) on such an interface w= ithout those non-ACP nodes having to support any ACP discovery or ACP chann= el setup. >=20 > > S 8.1.2. > > > only even more trusted software components will get access to bo= th > > > the ACP virtual subnet and the Data-Plane (because those ACP use= rs > > > could leak traffic between ACP and Data-Plane). This trust coul= d be > > > established for example through cryptographic means such signed > > > software packages. The specification of these mechanisms is sub= ject > > > to future work. > >=20 > > This all seems pretty handwavingly speculative. I would remove it >=20 > Why ? This is going on everywhere already inside data centers for example > in reorchestrated service provider pops where instead of plugging together > physical systems, VNF/NFV are orchestrated into trusted software based > network infrastructure. You're replacing the people operator verifying the > integrity/authenticity of physcial components with a software system doin= g the same. >=20 > > S 8.1.4. > > > legacy NMS Hosts that support only one IP interface. > > > =20 > > > To provide a single subnet into both ACP and Data-Plane, the ACP= Edge > > > node needs to de-multiplex packets from NMS hosts into ACP VRF a= nd > > > Data-Plane. This is sometimes called "VRF select". If the ACP = VRF > > > has no overlapping IPv6 addresses with the Data-Plane (as it sho= uld), > >=20 > > Does this mean it should have no overlapping addresses or it should > > have overlapping addresses? The text here is kind of unclear though I > > believe from context it is "should have no" >=20 > Replaced with "it should have no overlapping addresses" >=20 > > S 9.2.2. > > > under attack. > > > =20 > > > 9.2.2. From the inside > > > =20 > > > The security model of the ACP is based on trusting all members o= f the > > > group of nodes that do receive an ACP domain certificate for the= same > >=20 > > Nit: "receive", not "do receive" >=20 > Thanks >=20 > > S 10.2.3. > > > Even when such a malicious ACP registrar is detected, resolving = the > > > problem may be difficult because it would require identifying al= l the > > > wrong ACP domain certificates assigned via the ACP registrar aft= er it > > > was was compromised. And without additional centralized trackin= g of > > > assigned certificates there is no way to do this - assuming one = can > > > not retrieve this information from the . > >=20 > > from the .? >=20 > vi fumble. remove from " - assuming". >=20 > > S 10.2.4. > > > In situations, where either of the above two limitations are an > > > issue, ACP registrars could also be sub-CAs. This removes the n= eed > > > for connectivity to a root-CA whenever an ACP node is enrolled, = and > > > reduces the need for connectivity of such an ACP registrar to a = root- > > > CA to only those times when it needs to renew its own certificat= e. > > > The ACP registrar would also now use its own (sub-CA) certificat= e to > >=20 > > When you say "sub CA" do you mean "intermediate"? >=20 > I hope i am not fumbling on terminology. In the example given we only > need a chain of two CA, a root CA and another CA below it. I have most > often heard the term sub-CA used to describe this. I hope the description > applies more generically to any chain of two CA even if the actual hierar= chy > is longer, therefore i didn't use "assigning CA", which is what i heard > to be the term for the leaf CA. >=20 > "intermediate" sounds as if one is talking about at least three tiers of = CA. >=20 > Happy to take guidance if the termins to use should be improved. >=20 > > S 10.3.2.1. > > > provides also a high level of security because it only permits A= CP/ > > > ANI operations which are both well secured. Ultimately, it is > > > subject to security review for the deployment whether "admin dow= n" is > > > a feasible replacement for "physical down". > > > =20 > > > The need to trust into the security of ACP/ANI operations need t= o be > >=20 > > "trust into" is not grammatical >=20 > Removed "into" >=20 > > S 10.3.4. > > > whether or not to set "ACP/ANI enable". > > > =20 > > > The goal of automatically setting "ACP/ANI enable" on interfaces > > > (native or not) is to eliminate unnecessary "touches" to the nod= e to > > > make its operation as much as possible "zero-touch" with respect= to > > > ACP/ANI. If there are "unavoidable touches" such a creating/ > >=20 > > such as >=20 > Thanks >=20 > > S 10.3.5. > > > parameters on SIM card shipped to remote location), then the def= ault > > > should be to enable ACP/ANI. > > > =20 > > > 10.3.5. Node Level ACP/ANI enable > > > =20 > > > A node level command "ACP/ANI enable [up-if-only]" enables ACP o= r ANI > >=20 > > I got lost here. In what context does this command exist? >=20 > "node level" (Cisco IOS calls this "global configuration mode"). >=20 > > S 10.3.5.1. > > > =20 > > > Automatically setting "ANI enable" on brownfield nodes where the > > > operator is unaware of it could also be a critical security issue > > > depending on the vouchers used by BRKSI on these nodes. An atta= cker > > > could claim to be the owner of these devices and create an ACP t= hat > > > the attacker has access/control over. In network where the oper= ator > >=20 > > "In networks" >=20 > Gracias. >=20 > > S 10.3.6. > > > =20 > > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > > > reliable operations of the ACP if it can be executed by mistake = or > > > unauthorized. This behavior could be influenced through some > > > additional property in the certificate (e.g., in the domain > > > information extension field) subject to future work: In an ANI > >=20 > > This also seems handwavy. >=20 > I disagree. Encoding desired operational parameters into the certificates > is a simple to understand concept. In this case its a binary flag. >=20 > The problem is mostly how far we want to drive (ab)-using the certificate > as a carrier for configuration (which the ACP domain information field re= ally > is). Theoretical the answer is simple: Only for config you really can't do > via other configuration mechanisms available after enrolment. > And for this particular functionality i am not 100% sure how to judge it. >=20 > > S 15.2. > > > because it is not quite clear yet what exactly the implications = are > > > to make GRASP flooding depend on RPL DODAG convergence and how > > > difficult it would be to let GRASP flooding access the DODAG > > > information. > > > =20 > > > A.6. Extending ACP channel negotiation (via GRASP) > >=20 > > This section seems like it's entirely speculative. I recommend > > removing it. >=20 > This was for aforementioned dual stage secure channel negotiation. Given > how it came up in this discussion, i am curious to learn what you think > abou this option compared to the mechanism we have specified not in the > standards text. If there are simple reasons to rule out this type > of dual stage negotiation being useful in the future, i am happy to > remove, otherwise i would love to not loose the cycles invested into the > text (if we ever would want to finish it). >=20 > > That said, I don't really understand the rationale for multiple > > concurrent security protocols. If you have clear UDP on the network > > (and you must or none of this works), then you can do DTLS and IKEv2, > > so you should be able to have one side decide which to negotiate and > > negotiate that. Why does this not work? >=20 > Are you saying i would use a dual stage mechanism, where the first > stage is clear text ? The problem with that is that that UDP protocol > is additional attack surface. Thats why my initial proposal was this > dual-stage secure negotiation. But as mentioned initially, the first > stage becomes the lowest common denominator. >=20 > > S 15.2. > > > =20 > > > If multiple independent networks choose the same domain name but= had > > > their own CA, these would not form a single ACP domain because o= f CA > > > mismatch. Therefore there is no problem in choosing domain names > > > that are potentially also used by others. Nevertheless it is hi= ghly > > > recommended to use domain names that one can have high probabili= ty to > >=20 > > Are these normative? >=20 > Strange how you seem to be listing these under a section 15.2. >=20 > This text is in -16 from appendix A.7, so Informative (all of appendix). >=20 > > S 15.2. > > > If different domains have different CAs, they should start to tr= ust > > > each other by intent injected into both domains that would add t= he > > > other domains CA as a trust point during the ACP connection setu= p - > > > and then following up with the previous point of inter-domain > > > connections across domains with the same CA (e.g., GRASP > > > negotiation). > >=20 > > This all seems speculative (and hard to analyze at this state of > > handwaving). I suggest removal. >=20 > The purpose of appendix A is to capture in an informative fashion the sta= tus > of the work that the WG invested solving problems we would have liked to = solve (or > that the WG was very interested in discussing) - but which did not result > in output that allowed normative specification. >=20 > In the case of exchanging trust anchors/domain-names i think this is real= ly > not difficult to finish: You need to be have roles in certs indicating sp= ecific > ACP nodes (like registrars) are trusted intent originators, then you sign= a > piece of configuration in whatever format you like (YANG+transport encodi= ng) > with such a cert, flood it via ACP/GRASP (we have draft for that), and > e voila extended trust anchors/permissible ACP domain names.=20 >=20 > > S 15.2. > > > other domains CA as a trust point during the ACP connection setu= p - > > > and then following up with the previous point of inter-domain > > > connections across domains with the same CA (e.g., GRASP > > > negotiation). > > > =20 > > > A.8. Adopting ACP concepts for other environments > >=20 > > I would also remove this appendix. >=20 > There was interest from multiple WG members to have these explanations wr= itten > and included in the output of the WG.=20 >=20 > Just as a reminder: While the ADs seeding the ANIMA WG where very much fo= cussed > in producing standards track output to create immediate product applicabi= lity, > ANIMA is still an OPS WG and hence discussings about applicability to ma= rket segments > sould be a core interest of work output, and the ACP as specified in this= specification, > as good as it is, can not yet make all market segments happy, but future = work with > in comparison limited modifications could expand the ACP applicability. A= t least > that is our hope that we try to express in this section. >=20 > Thank you so much for your thorough review! >=20 From nobody Tue Jul 16 22:38:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E6120148; Tue, 16 Jul 2019 22:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, 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 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 uw8C6A216kBk; Tue, 16 Jul 2019 22:38:30 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062E512006B; Tue, 16 Jul 2019 22:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1080; q=dns/txt; s=iport; t=1563341909; x=1564551509; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=RwBR3FZYkxF6zKfdD1mfztw3x+bJCciBJS4CrSXBr+w=; b=SFm3cA1dXwHnkTrFgzkF772VpBYTrXUQ7K4I3kHkuDvjTQuP5TqyKm6y xBeyr86HKVZ20HbFRZ2oqwMJlKYKI+eASoNN5m56bD5Gr9ENjXEuQsOom cERjUpmJcxR+tUPi0ZvpYGP5Hk0cxQm29ixRrW2xQjoiKxLdzQFIKRla/ s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAAD5si5d/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4NVATIqhByIe4t5mnkCBwEBAQkDAQEvAQGEQAKCYDgTAQM?= =?us-ascii?q?BAQQBAQIBBW2FSIVKAQEBAQIBI1YFCwsOCiMHAgJXBhODIgGBew+se4EyhUe?= =?us-ascii?q?EbhCBNIFRiiWBf4E4H4JMPodPMoImBJRxlXIJghuCH4EMkGEbgh0BixmKU6F?= =?us-ascii?q?6gwsCBAYFAhWBZyGBWDMaCBsVZQGCQT6COo4PPQMwjjYBAQ?= X-IronPort-AV: E=Sophos;i="5.64,273,1559520000"; d="asc'?scan'208";a="14329259" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2019 05:38:27 +0000 Received: from [10.61.214.125] ([10.61.214.125]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6H5cP2L018818 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jul 2019 05:38:26 GMT From: Eliot Lear Message-Id: <2E629100-DC49-42F2-9DA9-7B8630B537FF@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_87312503-0E5C-46E1-8547-AE9BF4254FEB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 17 Jul 2019 07:38:25 +0200 In-Reply-To: <20190716220307.c5ajnwyjgskyjtqk@faui48f.informatik.uni-erlangen.de> Cc: Adam Roach , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, Michael Richardson , The IESG , Toerless Eckert , anima@ietf.org To: Toerless Eckert References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com> <20190716220307.c5ajnwyjgskyjtqk@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.125, [10.61.214.125] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 05:38:31 -0000 --Apple-Mail=_87312503-0E5C-46E1-8547-AE9BF4254FEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Toerless, > On 17 Jul 2019, at 00:03, Toerless Eckert wrote: >=20 >=20 > Not sure yet how to best do that, hopefully something we can discuss = @105. To the general idea=E2=80=A6 it may be worth setting some time at the = end of the ANIMA WG meeting for this, or even in the onboarding/mud side = meeting. This is an onboarding point=E2=80=A6 just likely after an = offboarding ;-) --Apple-Mail=_87312503-0E5C-46E1-8547-AE9BF4254FEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXS60UQAKCRBugA9nE248 uAEkAKCaftmzr751noMhQ+YqAB2i6iL9JACg1q28nsCMITutGFKhJYKRez9CmHw= =tX+E -----END PGP SIGNATURE----- --Apple-Mail=_87312503-0E5C-46E1-8547-AE9BF4254FEB-- From nobody Wed Jul 17 01:13:48 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0AE1201D0; Wed, 17 Jul 2019 01:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 waQKRIzg2GXF; Wed, 17 Jul 2019 01:13:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4161B12009C; Wed, 17 Jul 2019 01:13:44 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5EBCB54800E; Wed, 17 Jul 2019 10:13:39 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4DB46440041; Wed, 17 Jul 2019 10:13:39 +0200 (CEST) Date: Wed, 17 Jul 2019 10:13:39 +0200 From: Toerless Eckert To: Eliot Lear Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach , anima-chairs@ietf.org, Michael Richardson , The IESG , Toerless Eckert , anima@ietf.org Message-ID: <20190717081339.hr6z3nrzjr4kfipc@faui48f.informatik.uni-erlangen.de> References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <1692.1563030627@localhost> <77BE2D94-9701-417C-9703-BD6727A0FC4B@nostrum.com> <20190716220307.c5ajnwyjgskyjtqk@faui48f.informatik.uni-erlangen.de> <2E629100-DC49-42F2-9DA9-7B8630B537FF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E629100-DC49-42F2-9DA9-7B8630B537FF@cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 08:13:47 -0000 Definitely. My main point was more about the architecture vs. protocols: originally, ANIMA was chartered to avoid doing architectures, and it reflects in the difficulty to even get the reference model document accepted by our AD (for those who do not remembre). "Create only documents that result in running code". While that latter statement should clearly still be the outcome of further ANIMA work, my experience from the past years is that the structure of the charter 1 documents made it really difficult (impossible) to distinguish between the architecture of a solution and the details of the interoperaability protocols used to implement the architecture. In result, we had problems what to put into voucher, how to duplicate text in Netonf Zero touch and BRSKI and i am not even right now on top of all the IoT variations we may get where there likely will be fever (but some) additions to the architectural model, but more likely a lot more changes on the protocol side. So, i am ot quite sure how to best improve this in the future, but thats why i bring it up as food for thought. Cheers Toerless On Wed, Jul 17, 2019 at 07:38:25AM +0200, Eliot Lear wrote: > Hi Toerless, > > > On 17 Jul 2019, at 00:03, Toerless Eckert wrote: > > > > > > Not sure yet how to best do that, hopefully something we can discuss @105. > > To the general idea??? it may be worth setting some time at the end of the ANIMA WG meeting for this, or even in the onboarding/mud side meeting. This is an onboarding point??? just likely after an offboarding ;-) > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 17 02:21:30 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9B12063D; Wed, 17 Jul 2019 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1n-2adJ--qVR; Wed, 17 Jul 2019 02:21:18 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527A1120637; Wed, 17 Jul 2019 02:21:18 -0700 (PDT) Received: from 200116b82c292800c8cfb4743a3e4aca.dip.versatel-1u1.de ([2001:16b8:2c29:2800:c8cf:b474:3a3e:4aca]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hng7d-0006PD-Ni; Wed, 17 Jul 2019 11:21:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <24814.1563296511@localhost> Date: Wed, 17 Jul 2019 11:21:10 +0200 Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> <24814.1563296511@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1563355278;f881d165; X-HE-SMSGID: 1hng7d-0006PD-Ni Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 09:21:21 -0000 Hi! Please see below. > On 16. Jul 2019, at 19:01, Michael Richardson = wrote: >=20 >=20 > {I almost hit the 'n'ext key on this email when I read you had No > Objection... I wonder if the DT should link the comments in the DT > to the thread that results} No problem. I guess the discusses are more important to figure out first = anyway. >=20 > Mirja K=C3=BChlewind via Datatracker wrote: >> I agree with Alissa's discuss that the conclusion of section 10(.3) >> should be to recommend a manual configuration mode. Also with respect >=20 > okay. >=20 >> to section 10.2: if ownership is "enforced" by the manufacturer, = there >> should also probably be a way for the buyer to check if ownership was >> transferred by the saler during the re-sale process. >=20 > So you are asking for an additional API from the JRC to the MASA. > It would need to include something like: >=20 > a) a POST from selling-JRC to MASA to ask MASA for if a resale would = be granted. > This could result in some statement that the seller could show to = the > buyer that would validate that the transaction can occur. > b) a POST from selling-JRC to MASA to indicate to whom the sale was = made, > this would have to include some reference to the buyer. > c) a GET from the selling-JRc and also buyer-JRC that would ask who > the current owners is supposed to be. >=20 > (c) could in theory be done with the auditlog, provided that the (b) = process > installed the buyer as an authorized entity that could query the = auditlog. > It would probably be better to have the MASA do the thinking here, = rather > than the JRC. >=20 > I can imagine creating such APIs. There probably needs to be some > buyer-JRC/seller-JRC APIs, or at least conventions. This could easily = become > a rathole attracting all sorts of online sales API. Were this to be = added to > this document, or to an extension document, I'd want to have = significant > involvement from some people who build financial/sales systems, or at = least > =46rom the operations divisions of some buyers (operators) and sellers = (vendors). I was mostly thinking about discussing this case in the text, rather = than add a specific mechanism. E.g. you could say c) is an option that = can be used right away and a more dedicated interface could be = considered in future. >=20 >> Two other small comments on more load related points: >=20 >> 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid >> head of queue problems wherein an attacker running a fake proxy or >> registrar could perform protocol actions intentionally slowly. The >> pledge SHOULD continue to listen to for additional GRASP M_FLOOD >> messages during the connection attempts." One minor comment: Maybe >> also say explicitly, while running in parallel, one should not send = all >> initial messages at exactly the same time but pace them out (e.g. one >> every 3 secs) to avoid network overload when initial connectivity is >> very constraint. >=20 > I take your point. > In the ANIMA ACP situation, please think about the situation as being = a > multiport BFR with three+ 100G fiber connections to other cities. Or, = one or > more ports plugged into some (unmanaged or probably outsourced) L2 = fabric that > has multiple other ACP devices on it. I guess that doesn=E2=80=99t map to the IoT case that is also discussed = in the doc. However, this is a usual safety measure we are building in = all protocols (expect there is a good reason to do otherwise), e.g. also = for routing protocols, because you never know for sure how future = deployment scenarios will look like. >=20 >> 2) sec 4.3: " It must be sufficiently low that the aggregate amount = of >> periodic M_FLOODs from all EST servers causes negligible traffic = across >> the ACP." I know this is a little bit a blurry requirement but I = would >> still like to see a MUST here. Or maybe give an upper bound for the >> maximum frequency, e.g. MUST NOT send more than once per minute...? = Not >> sure it there is a reasonable value here. >=20 > I'm hesistant to write anything specific here. There are two reasons. > One is that we really don't have any experience running ACPs yet, or = how much > bandwidth will typically be available, and we also don't know how many = JRCs > a typical operator might deploy. >=20 > The second reason is that I think that this should really be dealt = with in: > = https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/= > (or mabe https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/) >=20 > ACP section 6.1.4.1 defines an M_FLOOD for the SRV.est. This is not > necessarily the JRC, btw, as certificate renewal might be performed by > a different system than enrollment. It does say: >=20 > The M_FLOOD message MUST be sent periodically. The default SHOULD = be > 60 seconds, the value SHOULD be operator configurable but SHOULD be > not smaller than 60 seconds. The frequency of sending MUST be such > that the aggregate amount of periodic M_FLOODs from all flooding > sources cause only negligible traffic across the ACP. >=20 > I will copy this text. That would be good! Thanks! Mirja >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Wed Jul 17 10:05:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4D12072D; Wed, 17 Jul 2019 10:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Oz9TCY-c9uec; Wed, 17 Jul 2019 10:04:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14939120699; Wed, 17 Jul 2019 10:04:39 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id D51D73808A; Wed, 17 Jul 2019 13:04:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 08F70AC2; Wed, 17 Jul 2019 13:04:38 -0400 (EDT) From: Michael Richardson To: Mirja Kuehlewind cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: References: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> <24814.1563296511@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 17:04:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mirja Kuehlewind wrote: >> okay. >>=20 >>> to section 10.2: if ownership is "enforced" by the manufacturer, >>> there should also probably be a way for the buyer to check if >>> ownership was transferred by the saler during the re-sale process. >>=20 >> So you are asking for an additional API from the JRC to the MASA. It >> would need to include something like: >>=20 >> a) a POST from selling-JRC to MASA to ask MASA for if a resale would >> be granted. This could result in some statement that the seller cou= ld >> show to the buyer that would validate that the transaction can occur. >> b) a POST from selling-JRC to MASA to indicate to whom the sale was >> made, this would have to include some reference to the buyer. c) a >> GET from the selling-JRc and also buyer-JRC that would ask who the >> current owners is supposed to be. >>=20 >> (c) could in theory be done with the auditlog, provided that the (b) >> process installed the buyer as an authorized entity that could query >> the auditlog. It would probably be better to have the MASA do the >> thinking here, rather than the JRC. >>=20 >> I can imagine creating such APIs. There probably needs to be some >> buyer-JRC/seller-JRC APIs, or at least conventions. This could easi= ly >> become a rathole attracting all sorts of online sales API. Were this >> to be added to this document, or to an extension document, I'd want = to >> have significant involvement from some people who build >> financial/sales systems, or at least From the operations divisions of >> some buyers (operators) and sellers (vendors). > I was mostly thinking about discussing this case in the text, rather > than add a specific mechanism. E.g. you could say c) is an option that > can be used right away and a more dedicated interface could be > considered in future. The auditlog can not be used in advance to see if ownership will be transfered. It's retrospective. So it does not provide a way for the buy= er to check if ownership can/will be transfered. We would still need (b) in order to notify the MASA of the intent to sell. If the IETF wants to get into APIs for sales integration, I would be there, but my feeling is that this is layers above where we normally go. (My colleague Joseph Potvin hopes to convince us otherwise with with a HotRFC talk on sunday). >>> Two other small comments on more load related points: >>=20 >>> 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid >>> head of queue problems wherein an attacker running a fake proxy or >>> registrar could perform protocol actions intentionally slowly. The >>> pledge SHOULD continue to listen to for additional GRASP M_FLOOD >>> messages during the connection attempts." One minor comment: Maybe >>> also say explicitly, while running in parallel, one should not send >>> all initial messages at exactly the same time but pace them out >>> (e.g. one every 3 secs) to avoid network overload when initial >>> connectivity is very constraint. >>=20 >> I take your point. In the ANIMA ACP situation, please think about t= he >> situation as being a multiport BFR with three+ 100G fiber connections >> to other cities. Or, one or more ports plugged into some (unmanaged = or >> probably outsourced) L2 fabric that has multiple other ACP devices on >> it. > I guess that doesn=E2=80=99t map to the IoT case that is also discuss= ed in the > doc. However, this is a usual safety measure we are building in all > protocols (expect there is a good reason to do otherwise), e.g. also > for routing protocols, because you never know for sure how future > deployment scenarios will look like. I have added some text as you suggest, btw. I am concerned about the "IoT case that is also discussed", as we are trying hard to not say anything normative about IoT in *this* document, because one size does not fit all. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0vVSUACgkQgItw+93Q 3WWi/QgAt8aFdjz3t4Od+b7rFCQSl07Tj//LF0aKoFvaFoIsevW0aVepOuzIKklf Iq6/9Ej0uiwACdmcfiScZk+zbZrtspFbtVamn4SmUYMDOPDNlMjcdvkVOs4G4/07 DnSyauJH7n/Fp8mx/QyLCk0ph5GqVrAWWhRKSdqAiWXcbBvmY5fEPtDrY0dC/kvC ymFIL4Y0bjnWtUvKWA2gknzY5rHUCNctUJUdl2emB5GYGzejHVTJyH2uxWCD6bVs 1NeqMUnd0wfZqruJz8aev2CbCIq+QZK4zpmkxXEbmXUDPUfGaPS/6Pt3iHBYNh+f 5VxkCDfnLQkJnzwMwGbU5RT3uMR0YA== =jaxL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 17 10:10:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21956120786 for ; Wed, 17 Jul 2019 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3MdxwTLdbgha for ; Wed, 17 Jul 2019 10:10:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F57B12072D for ; Wed, 17 Jul 2019 10:10:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 182803808A; Wed, 17 Jul 2019 13:10:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41B128EF; Wed, 17 Jul 2019 13:10:48 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org, lamps@ietf.org, Sean Turner , Ignas Bagdonas , max pritikin , Benjamin Kaduk In-Reply-To: <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> References: <6535.1560786935@dooku.sandelman.ca> <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 17:10:53 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > Errata 5107 on the other hand seems to be asking to remove CTE header > by default, but doesn't really say what to do with 7030 base64 payloa= d. > One could interpret it to send binary which would be backward > incompatible, or one could interpret it as sending base64 by mutual > agreement, but without explicitly writing this into a text its > guesswork. Based upon feedback on the -00 and -01, it appears that nobody actually sen= ds the CTE header, so we have no signal about it being binary or base64, and everyone just sends base64. So the clarification becomes that the CTE header is redundant, should be ignored, and the payload is always base64. If we did an rfc7030bis, then we might define new end-points, but that seems like busy work to me. > What seems to be incomplete in your draft is whether to send or not to > sent CTE, it only says to ignore it upon receipt. So, whats the minim= um > requirement for fully backward compatibility on sending ? always base64 the payloads >> 4) ANIMA BRSKI needs to clarify things itself, and I will add a >> section on this, but I'm hesistant to add a normative reference here. >> I have an idea of appropriate text that I will post on Tuesday. >> Getting clarity here is really the most important thing for me. > I would like to see avoiding to drag this issue into BRSKI text unless > we have to. I would simply have a reference to this draft in BRSKI and > one sentence about it near the first mentioning of 7030 in BRSKI. I have added a section to BRSKI that clarifies that, despite EST7030 being base64 encoded, BRSKI payloads (voucher, voucher-request) are binary. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0vVpcACgkQgItw+93Q 3WV41gf/d5HQKZWZLZjUIsahwDBhNZfUTiU91KFzcuTliLRAPVlS/AFYh6Fi31DS /blvu1KQDIAmS0qMRs1aa16OGtodKYqTwoMfL7yLCaExb6GS0foV23vxTSmHIJb5 oYuOtf+49kza9PQD95xz1hwrRDbtFv+aYiGsbuzhGeCSHD/aRymAOGBWuI2MAROn CEyR4scZ2R9BatbRIk547zQAF5V4Ytl766AvoJ/YnOIK5vmUn9yzIwQeFSh3ZpoD iHF+Hdh2507xvhlGBIjoo8d13MSXum5JSBRwAqsKgAkMuJudpd77QQNWojhuKag5 E856RKLrjH2b2UteIybBeR2S8knKlg== =JkTI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 17 10:39:52 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7634D120861 for ; Wed, 17 Jul 2019 10:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 upz0pLAnDL7s for ; Wed, 17 Jul 2019 10:39:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268C4120848 for ; Wed, 17 Jul 2019 10:39:47 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D8B7454800B; Wed, 17 Jul 2019 19:39:42 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C966A440041; Wed, 17 Jul 2019 19:39:42 +0200 (CEST) Date: Wed, 17 Jul 2019 19:39:42 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, lamps@ietf.org, Sean Turner , Ignas Bagdonas , max pritikin , Benjamin Kaduk Message-ID: <20190717173942.bqhp2jzk4yeoaifl@faui48f.informatik.uni-erlangen.de> References: <6535.1560786935@dooku.sandelman.ca> <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> <17732.1563383448@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17732.1563383448@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 17:39:51 -0000 On Wed, Jul 17, 2019 at 01:10:48PM -0400, Michael Richardson wrote: > Toerless Eckert wrote: > > Errata 5107 on the other hand seems to be asking to remove CTE header > > by default, but doesn't really say what to do with 7030 base64 payload. > > One could interpret it to send binary which would be backward > > incompatible, or one could interpret it as sending base64 by mutual > > agreement, but without explicitly writing this into a text its > > guesswork. > > Based upon feedback on the -00 and -01, it appears that nobody actually sends > the CTE header, so we have no signal about it being binary or base64, and > everyone just sends base64. So the clarification becomes that the CTE > header is redundant, should be ignored, and the payload is always base64. Great. That could be written more explicitly in the draft. > If we did an rfc7030bis, then we might define new end-points, but that seems > like busy work to me. Agreed. A small update RFC will be much more economical and if well written also much easier to understand. > > What seems to be incomplete in your draft is whether to send or not to > > sent CTE, it only says to ignore it upon receipt. So, whats the minimum > > requirement for fully backward compatibility on sending ? > > always base64 the payloads I figured that. But i think you are also saying that you do not need to send CTE to be backward compatible, thats even better. > >> 4) ANIMA BRSKI needs to clarify things itself, and I will add a > >> section on this, but I'm hesistant to add a normative reference here. > >> I have an idea of appropriate text that I will post on Tuesday. > >> Getting clarity here is really the most important thing for me. > > > I would like to see avoiding to drag this issue into BRSKI text unless > > we have to. I would simply have a reference to this draft in BRSKI and > > one sentence about it near the first mentioning of 7030 in BRSKI. > > I have added a section to BRSKI that clarifies that, despite EST7030 being > base64 encoded, BRSKI payloads (voucher, voucher-request) are binary. Thats ok. to ensure that BRSKI is as independent of an rfc7030 update draft as possible, but it would be good to also suggest doing this in your updte draft so that any other rfc7030 extensions could foolow that lead. Btw: If there is no more feedback from the WGs you addressed in this mail, please consider asking for a slot on the agenda of eithre of them anyhow. Much harder for them to ignore the issue in email than in the room ;-) (which of course doesn't mean that we shouldn't discuss in ANIMA, but i guess we agree that any better http/est? expert opinion input would be helpfull). Cheers toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From nobody Wed Jul 17 14:13:25 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5F1201E5 for ; Wed, 17 Jul 2019 14:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 REMEHQ-bxalI for ; Wed, 17 Jul 2019 14:13:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB8A1200FD for ; Wed, 17 Jul 2019 14:13:15 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 0575B3808A; Wed, 17 Jul 2019 17:13:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 98777AC2; Wed, 17 Jul 2019 17:13:13 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" cc: Adam Roach , anima@ietf.org, Eliot Lear In-Reply-To: References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <5240.1563306433@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:13:20 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > Thank you Michael. I saw the proposed change in section 9. I wonder > if that is hiding the MUST, since the mechanisms are in section 7... > Having said that, I can live with it as you have proposed. I take your point. Options I see are: 1) swap the sections so section 9 (applicability) comes before 7 (reduced s= ecurity) 2) mention the ACP applicability in section 7. 3) move the 7.2 section to section 9. The intention with section 7 is to provide a palette of things, and let their use be dictated by how the protocol is applied. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0vj2kACgkQgItw+93Q 3WULwAf/c2LdaCacAEquOWgoRajbFn85CctGKKdznAL+l4ETm2Vj6ITKqw0l+mhv RCO4Tu5g7fqPzS1F/7rrQMCPvfb12DB/lhJ7efuDaOj1AlWcZFt6f5lLZtbEv9uP 1rkwisjIQ6TpF7ZvS96Jw9DH6mw38cLBXHpE+cFPtTmAjt7v/8qS51cLqeWrRKlB WjWJJtRAs+ZLmfB5pdUccdnNa1XnIH4i3OnUwaR2sS6M/JiiNWO52nJ34dHG2VZk 0aOaMhfUCxasK6m1bn/fKqqfU6fahvJjeTbtnrAbTOcDRC3/Gp9TRv9TdGINTRKP SNO3ixnqbFqiAIuKnFLm5fZ6Xh4U1Q== =cWp5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 17 14:55:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF01200E7 for ; Wed, 17 Jul 2019 14:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IsRySrMIepsd for ; Wed, 17 Jul 2019 14:55:19 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDBF120096 for ; Wed, 17 Jul 2019 14:55:19 -0700 (PDT) Received: from client-0206.vpn.uni-bremen.de (client-0206.vpn.uni-bremen.de [134.102.107.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45prfY45GyzyPH; Wed, 17 Jul 2019 23:55:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <17732.1563383448@localhost> Date: Wed, 17 Jul 2019 23:55:16 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 585093314.893635-dd8bda2673b4a256a24f310dbbb5bf27 Content-Transfer-Encoding: quoted-printable Message-Id: <37592AA0-87AB-4036-93A9-B60F56539F53@tzi.org> References: <6535.1560786935@dooku.sandelman.ca> <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> <17732.1563383448@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 21:55:21 -0000 On Jul 17, 2019, at 19:10, Michael Richardson = wrote: >=20 > always base64 the payloads Which means that the content-type headers lie. Backwards combyativbility [actual autocorrect result :-)] can be nasty. But sniffing this out should be easy. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 18 07:25:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B33120305 for ; Thu, 18 Jul 2019 07:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 KsZ96TPxJq0g for ; Thu, 18 Jul 2019 07:24:57 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4705120363 for ; Thu, 18 Jul 2019 07:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45qGcR65h6zQj8C; Thu, 18 Jul 2019 07:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563459895; bh=iOjNqNkZl9S6VUknLnGyWzf5olbr46ky2b60vVU+luo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=B9xl7smoJuITuzty50qki2v2dc692kYYKmvDjEOEnltS5IR7I3nsP4F/fhSpPVaVl eJjl3rkIVjg8zkBAO6mNtG6lPHNZq4nWAB7MMbY7vtiPuPaBiudfBLSbPNi3YfCflE fbR3IGfVHHAAjo5poguoeLgmS3fKf80qwVd5/5ng= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45qGcQ5W4NzQj7v; Thu, 18 Jul 2019 07:24:54 -0700 (PDT) To: Michael Richardson Cc: Adam Roach , anima@ietf.org, Eliot Lear References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <8869.1563140002@dooku.sandelman.ca> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com> <6ecdae7f-4fb7-d9fc-f19f-bf742c6fe83c@joelhalpern.com> <193EB8D1-3E58-4570-AC4D-55737E3D36CF@cisco.com> <5240.1563306433@localhost> <15321.1563397993@localhost> From: "Joel M. Halpern" Message-ID: <92439d44-1a2c-5b5f-1d3f-8985c4727727@joelhalpern.com> Date: Thu, 18 Jul 2019 10:24:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <15321.1563397993@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 14:24:59 -0000 All three of those sound like improvements. WHichever one you and the working group pick would clearly help. Thank you, Joel On 7/17/2019 5:13 PM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > Thank you Michael. I saw the proposed change in section 9. I wonder > > if that is hiding the MUST, since the mechanisms are in section 7... > > Having said that, I can live with it as you have proposed. > > I take your point. Options I see are: > 1) swap the sections so section 9 (applicability) comes before 7 (reduced security) > 2) mention the ACP applicability in section 7. > 3) move the 7.2 section to section 9. > > The intention with section 7 is to provide a palette of things, and let > their use be dictated by how the protocol is applied. > From nobody Thu Jul 18 08:00:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A89120784; Thu, 18 Jul 2019 08:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ibFZ63EtIJm9; Thu, 18 Jul 2019 08:00:24 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4FC120780; Thu, 18 Jul 2019 08:00:24 -0700 (PDT) Received: from 200116b82c886c005093af0e85c019b4.dip.versatel-1u1.de ([2001:16b8:2c88:6c00:5093:af0e:85c0:19b4]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ho7tK-00081X-LD; Thu, 18 Jul 2019 17:00:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <16131.1563383078@localhost> Date: Thu, 18 Jul 2019 17:00:17 +0200 Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156285232840.32370.18027192977627346503.idtracker@ietfa.amsl.com> <24814.1563296511@localhost> <16131.1563383078@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1563462024;c161fedb; X-HE-SMSGID: 1ho7tK-00081X-LD Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-bootstrapping-keyinfra-22=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 15:00:30 -0000 Hi Michael, Okay sounds good. See some minor comments below. > On 17. Jul 2019, at 19:04, Michael Richardson = wrote: >=20 >=20 > Mirja Kuehlewind wrote: >>> okay. >>>=20 >>>> to section 10.2: if ownership is "enforced" by the manufacturer, >>>> there should also probably be a way for the buyer to check if >>>> ownership was transferred by the saler during the re-sale process. >>>=20 >>> So you are asking for an additional API from the JRC to the MASA. = It >>> would need to include something like: >>>=20 >>> a) a POST from selling-JRC to MASA to ask MASA for if a resale would >>> be granted. This could result in some statement that the seller = could >>> show to the buyer that would validate that the transaction can = occur. >>> b) a POST from selling-JRC to MASA to indicate to whom the sale was >>> made, this would have to include some reference to the buyer. c) a >>> GET from the selling-JRc and also buyer-JRC that would ask who the >>> current owners is supposed to be. >>>=20 >>> (c) could in theory be done with the auditlog, provided that the (b) >>> process installed the buyer as an authorized entity that could query >>> the auditlog. It would probably be better to have the MASA do the >>> thinking here, rather than the JRC. >>>=20 >>> I can imagine creating such APIs. There probably needs to be some >>> buyer-JRC/seller-JRC APIs, or at least conventions. This could = easily >>> become a rathole attracting all sorts of online sales API. Were = this >>> to be added to this document, or to an extension document, I'd want = to >>> have significant involvement from some people who build >>> financial/sales systems, or at least =46rom the operations divisions = of >>> some buyers (operators) and sellers (vendors). >=20 >> I was mostly thinking about discussing this case in the text, rather >> than add a specific mechanism. E.g. you could say c) is an option = that >> can be used right away and a more dedicated interface could be >> considered in future. >=20 > The auditlog can not be used in advance to see if ownership will be > transfered. It's retrospective. So it does not provide a way for = the buyer > to check if ownership can/will be transfered. We would still need (b) = in > order to notify the MASA of the intent to sell. >=20 > If the IETF wants to get into APIs for sales integration, I would be = there, > but my feeling is that this is layers above where we normally go. (My > colleague Joseph Potvin hopes to convince us otherwise with with a = HotRFC > talk on sunday). Okay understood. I guess you could still say in this document that = should a mechanism would be useful but left for future work = (somewhere)... >=20 >>>> Two other small comments on more load related points: >>>=20 >>>> 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid >>>> head of queue problems wherein an attacker running a fake proxy or >>>> registrar could perform protocol actions intentionally slowly. The >>>> pledge SHOULD continue to listen to for additional GRASP M_FLOOD >>>> messages during the connection attempts." One minor comment: Maybe >>>> also say explicitly, while running in parallel, one should not send >>>> all initial messages at exactly the same time but pace them out >>>> (e.g. one every 3 secs) to avoid network overload when initial >>>> connectivity is very constraint. >>>=20 >>> I take your point. In the ANIMA ACP situation, please think about = the >>> situation as being a multiport BFR with three+ 100G fiber = connections >>> to other cities. Or, one or more ports plugged into some (unmanaged = or >>> probably outsourced) L2 fabric that has multiple other ACP devices = on >>> it. >=20 >> I guess that doesn=E2=80=99t map to the IoT case that is also = discussed in the >> doc. However, this is a usual safety measure we are building in all >> protocols (expect there is a good reason to do otherwise), e.g. also >> for routing protocols, because you never know for sure how future >> deployment scenarios will look like. >=20 > I have added some text as you suggest, btw. > I am concerned about the "IoT case that is also discussed", as we are = trying > hard to not say anything normative about IoT in *this* document, = because one > size does not fit all. Yes, but even though you never now how such protocols are used in the = end. And either your make clear that usage is clearly restricted to = certain scenario for a good reason or you try to cover as much as you = can. Mirja >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 From nobody Thu Jul 18 09:02:48 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E159A1207EE; Thu, 18 Jul 2019 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=q+Gh02Ow; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oWBNJIwG 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 bnT90ATtk3Kf; Thu, 18 Jul 2019 09:02:43 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63B91207BD; Thu, 18 Jul 2019 09:02:43 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CB66A42B; Thu, 18 Jul 2019 12:02:42 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 18 Jul 2019 12:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=sSwuYLZdAoHA+sFeG0WfrLbNYe5BEC6 GDrTdpCuCm18=; b=q+Gh02Ows336cDFbgKvzaq2MWewTZBackqQgrRgK6OldzsF /Ngo0wE0IuX1Pr0+hm2xdi96QVw2jdRS/DInzqTUEJlcQQ16QEUdAdplf4KkTFMK swMCpOL2LqiyXItowjbpV4/1F0C68qrKIVT64rDC8A10rif/7cuMjdRNMwMpOPtJ o0uZBK9r2L8ImzojnpvDEBC5sVON1NirtxGo890YfvoB+uc1Q5YUfb+GRxV5JC2x aGO7c/2mhJZns4Uqd/AJjiGqqTnxQ/V7A7X3Dk0+1S+lfPP7a5QFoxTKMH/QBHPG uP44yEdvxSzOvV6TG0RY0mKPjpoJyKF/98cCzLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=sSwuYL ZdAoHA+sFeG0WfrLbNYe5BEC6GDrTdpCuCm18=; b=oWBNJIwGNy6UAu16smi0aK mQLOJYocVZS/qt64tDSHd0+DB/0A1e8M7bXZ+SZtKRnaHMLzIgw+tc7CJgxKCbjE xD1g7v+56TJ4CxFBWM4wC61XddlBWPIYqaUoXZVVWbzmZy+w57XR9GzhIyY9AZj6 SGJd3g9JRVVFctFb1Bg7Z618eMwiu8UFVFP7nhBaonpIeoFvR1GhZStY5iGzXaIv MITNBBqFLiTZCmRtL6W0bHlXs4yb338Ooir4n5Ab7xWwcFyyAOm6O200kzoV7c+Q F4YJ7mIKQPECdGZJYuQFeY6zkZwffwlu6lJOYcw6fCwMnzeQTYY0d+P1yAto5m3g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieehgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgrnhgrrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CA39CC200A4; Thu, 18 Jul 2019 12:02:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <29770.1563061936@dooku.sandelman.ca> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <29770.1563061936@dooku.sandelman.ca> Date: Thu, 18 Jul 2019 17:02:11 +0100 From: "Alexey Melnikov" To: "Michael Richardson" Cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Anima] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-anim?= =?utf-8?q?a-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 16:02:46 -0000 Hi Michael, On Sun, Jul 14, 2019, at 12:52 AM, Michael Richardson wrote: > Alexey Melnikov via Datatracker wrote: > > 5) In 8.1: > > > This document extends the definitions of "est" (so far defined via > > RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ > > well-known-uris.xhtml" registry as follows: > > > o add /.well-known/est/requestvoucher (see Section 5.5 ) > > > o add /.well-known/est/requestauditlog (see Section 5.7) > > > The .well-known URIs IANA registry doesn't list anything below the > > first level (i.e. "est" in your case). So I think you really want to > > have 2 IANA actions here: > > > a) Add the reference to this document as another reference for "est". > > > b) create a new registry of "est" URIs and add your 2 URIs above to it > > and also populate other entries from the original EST RFC. > > The advice we got from the .well-known expert was that we should have this > document Updates: RFC7030, and that the /est entry in the registry > should say "RFC7030, RFCXXXX". Will this be enough rather than create > a new registry? We think that no other /.well-known has a registry. > > Tell us which way to go. I think the answer depends on whether you want to have an easy way of finding second level URI path components under "est". I personally prefer a new registry, but I understand that it might be a bit more work in the document. > > 2.7. Cloud Registrar > > > If the pledge uses a well known URI for contacting a cloud registrar > > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > > authenticate service as described in [RFC6125]. > > > Just referencing RFC 6125 is not clear enough, as there are lots of > > parameters that need to be specified: > > > a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards > > allowed in any of these? > > We think it's up to the manufacturer to define a policy here. > This section is an out for manufacturers that wish to provide some call-home > mitigation for when the device is deployed where no ACP can be found. > Maybe saying "well known URI" is causing a mis-understanding? On a re-read, the current text looks Ok as is. Best Regards, Alexey From nobody Thu Jul 18 09:06:43 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D741D120807; Thu, 18 Jul 2019 09:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Y3YMBFIT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=y7Lqu1Af 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 TXwrfH-g6H2K; Thu, 18 Jul 2019 09:06:39 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088A81207FC; Thu, 18 Jul 2019 09:06:38 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id E078F403; Thu, 18 Jul 2019 12:06:36 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 18 Jul 2019 12:06:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=EyljDjYK7oGo9sxVpgQeUP4hnhZtqh2 eVVAp2rKI3Ic=; b=Y3YMBFITy94M45aejIRJkDLSyasQwWP0nqNtxJZw5wT9Vq6 lP3tp+/AzG70haTkEXSX9WRG+/+I2VX95KQD4iBZv4edfNKmAPdY1nY7gZmLYtN8 Nv/UKQj64BYbyarDVXTC+BgwGj9whxwrRs0xwc9kSPjs7Lu7Qm+lM2Gy+jH9csvG OeFRc/QKOcfqj3ERWYXaVyEtmY4o18Ic5jHj1z2GwJtINMRR78b/zd++P9Aul2mr 1RUgzNewDHNDKh2GknD9cZt0+1BTNzY4F/BWLoc77g8Auo7uLYrbPH0A+vqiXzcj 8yhpcIBORc5LnWkwB8N7TP4lZVgIxNdpgzcKlWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EyljDj YK7oGo9sxVpgQeUP4hnhZtqh2eVVAp2rKI3Ic=; b=y7Lqu1AfRbZ7VSNZZVI2We DIJR4JKSOEgKFlInvV1/YxzNzHsEsw1v/VNKDkHMlnpdjp/AKvNy7etqctCKitsP D4NkYe2Yu6AA7w96iyRaUxioIztWrDWXp1uWWSd14e8jTMXS1itEf7wwxXbpX7zO COlUMlr4EvSunbJ3lF3mcCRJ0oDQtmexx6hKBHi9wo1M5xKiH5xf2zw5d3S3QhCq wN64KTNhBsd/uA+FOkl22JAe8/8LNyplSzkol36+mP/9RqBo1RH1ExDCWxutD6CG arrg4ke9IF0vYDY/98hQhPRw46oxWdbAs+iLxvENrn8u/j5YYVaOok3F3ql00eTQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieehgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhf rhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3FA6EC200A4; Thu, 18 Jul 2019 12:06:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <27800.1563297174@localhost> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <27800.1563297174@localhost> Date: Thu, 18 Jul 2019 17:06:06 +0100 From: "Alexey Melnikov" To: "Michael Richardson" Cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Anima] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-anim?= =?utf-8?q?a-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 16:06:41 -0000 Hi Michael, On Tue, Jul 16, 2019, at 6:12 PM, Michael Richardson wrote: > Alexey Melnikov via Datatracker wrote: > > 1) In Section 5: > > > o In the language of [RFC6125] this provides for a SERIALNUM-ID > > category of identifier that can be included in a certificate and > > therefore that can also be used for matching purposes. The > > SERIALNUM-ID whitelist is collated according to manufacturer trust > > anchor since serial numbers are not globally unique. > > > I think now you are just inventing things. Please define what exactly > > SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed. > > https://github.com/anima-wg/anima-bootstrap/commit/2f4cee70fc583c60a4589c983043a346ac0145ea > > new text reads: > This extends the informal set of "identifer type" values defined in > to include a SERIALNUM-ID > category of identifier that can be > included in a certificate and > therefore that can also be used for matching > purposes. As noted > in that document this is not a formal definition as > the underlying > types have been previously defined elsewhere. The > SERIALNUM-ID whitelist is collated > according to manufacturer > trust anchor since serial numbers are not globally > unique. This is actually not helping. I was looking for something like: DNS-ID = a subjectAltName entry of type dNSName Basically I was asking for a definition of SERIALNUM-ID somewhere. Best Regards, Alexey From nobody Thu Jul 18 16:30:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBB120115; Thu, 18 Jul 2019 16:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PG40f7V1qbtT; Thu, 18 Jul 2019 16:30:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBA3120106; Thu, 18 Jul 2019 16:30:13 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E8A83808A; Thu, 18 Jul 2019 19:30:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4F0D71B; Thu, 18 Jul 2019 19:30:10 -0400 (EDT) From: Michael Richardson To: "Alexey Melnikov" cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <27800.1563297174@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 23:30:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Alexey Melnikov wrote: >> > o In the language of [RFC6125] this provides for a SERIALNUM-ID > >> category of identifier that can be included in a certificate and > >> therefore that can also be used for matching purposes. The > >> SERIALNUM-ID whitelist is collated according to manufacturer trust > >> anchor since serial numbers are not globally unique. > This is actually not helping. I was looking for something like: > DNS-ID =3D a subjectAltName entry of type dNSName > Basically I was asking for a definition of SERIALNUM-ID somewhere. It's a (subject)DN of serial number=3D123456, not a subjectAltName. (not the CertificateSerialNumber) It's X.520.. via 802.1AR and RFC5280 section 4.1.2.4. https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-X.520-201610-I!= !PDF-E&type=3Ditems section 6.2.9. o Client authentication is automated using Initial Device Identity (IDevID) as per the EST certificate based client authentication. The subject field's DN encoding MUST include the "serialNumber" =2D attribute with the device's unique serial number. + attribute with the device's unique serial number as explained in + Section 2.3.1 =20 =2D o This extends the informal set of "identifer type" values defined =2D in [RFC6125] to include a SERIALNUM-ID category of identifier that =2D can be included in a certificate and therefore that can also be =2D used for matching purposes. As noted in that document this is not =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0xAQIACgkQgItw+93Q 3WXkNAgAjae4f+J6oQavDtV0wksumMavJ32tYGEnRVqJQTDx/Ib2bu5BjLCOYRod zE9U6dFz10Ns/N6lvETC4dfsdkW2dBE6RHWAJaJ9LWYOqE4mJMcS8pkQO3d1No2b VBtVSaX1aZUSf9RhF7MwtbJDzr454ujF8suH+3wlUgksj4oBwRsz12S/4qhTJ9O8 y5JrZyMxsb9r1ZhLklVRWQ6flIJzjYQy9auJwUxSORhkkey8bt6hLqK5kByikmX/ CgB5/lQ6QGPX5fZ/t7z02NCcqxARiih911gJzGlUssgYegE7z8eYdRMWW3hyZLkx GmzxLoe9L3Ypwnb6xIN78hrK7Pju1w== =0QXJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 18 16:31:23 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205A120115; Thu, 18 Jul 2019 16:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2G3SURYTAzh5; Thu, 18 Jul 2019 16:31:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627EB120106; Thu, 18 Jul 2019 16:31:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BC803808A; Thu, 18 Jul 2019 19:31:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E26571B; Thu, 18 Jul 2019 19:31:09 -0400 (EDT) From: Michael Richardson To: "Alexey Melnikov" cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <29770.1563061936@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2019 23:31:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Alexey Melnikov wrote: >> The advice we got from the .well-known expert was that we should have >> this document Updates: RFC7030, and that the /est entry in the >> registry should say "RFC7030, RFCXXXX". Will this be enough rather >> than create a new registry? We think that no other /.well-known has= a >> registry. >>=20 >> Tell us which way to go. > I think the answer depends on whether you want to have an easy way of > finding second level URI path components under "est". I personally > prefer a new registry, but I understand that it might be a bit more > work in the document. I prefer Updates: 7030. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0xATwACgkQgItw+93Q 3WUJHQf8CmyhP9ppcdPGb1rYEyeFhK9PN2jkeOYMbOWo036sVWURsnqrlxP6a9hs 1w8pVKtilUNp6GXUtVeNGxxLqKA4BcJT1dn+CxeAG4t7RS0xe0PVJS0g3QBETOfg I4cqxXuqJ/qxhi6SADUuBpuOTjlxNnWH7GCfo3madQn/tXKR4w8tgA8lOyZ9evH+ IqjC1fglM8kOWgg3cVF1YUduYtB00umzyakdPEgdNPkKim3asNDybAf6tWQ7Yzud tbQ+WvYXco89GL96HId+4dX+u/391nf0pDA1qpH+mkLuiNTWAwbtuM/JG6AeqOd3 lor1ohhCdzMBqCODt9bIFTkiRheawA== =Y9pR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 19 04:37:34 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190FB12001E; Fri, 19 Jul 2019 04:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=jLa14DCo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f0s/4wiv 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 hmwKFsw9D2Ht; Fri, 19 Jul 2019 04:37:23 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425CF1201B4; Fri, 19 Jul 2019 04:37:23 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 48AC04EF; Fri, 19 Jul 2019 07:37:22 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 19 Jul 2019 07:37:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=YWB7VSqVdeKA4hmx274cawt+bnTQTK4 aJsHFdWQHXP0=; b=jLa14DCoLIAYChCnZUi86BFFtio18SHBVvtasShKygaOoyU 9NE4xyrBbpaxgEG9GzNhSEfCChv1gKe1wv000T3S0Ih9BkZbpNU5tKcrJMqYRqVi 3rmrFdz1IJYT4c8ghldvfhwM6cAmZENFz4yqpBGfIL82QErhkGPkyeXNgF5LRaQx CewCOuqyJ3+QGVtMCjcmH+VsL21z0fRzQwulqQVrYciJpTghHKZ/EeZafp9X7+nq XleDQJGGOeiLmRFH7mt7Ce7KBTi8/asvAcmJAn3G5oEVWZ/RE4TFl8EjIoD/snfd roMtZC1iG5Tl8Du3roPuWI/9qdiG4R2Gx+vpC4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=YWB7VS qVdeKA4hmx274cawt+bnTQTK4aJsHFdWQHXP0=; b=f0s/4wivRlizJTNtjebl/d gshF+DWax4sp7mIX+Ibqc95ovGlC4YsmTpOvHf7v97lv5f+dvgdCceXzg1OQymtT jZK8WM3k3i28sZu22HOFp2otlGckMVKsjbbOOsklHneXGacBm/d5gXtSUVqvQll1 NVEUE4Ha6TngMEOkwZSi1sP/zBSZeiD3s5iOp6XLOBebVv4fS+QzMetesAohR6WS CLCYOWyaywtn5MIvrXzRroi3a1KXHVV0udBzw1PW0uSFYLRMkLZRBMOwjX5yDz2P xz2fKkQFC7ts7dGcjz3Tt+YuPSpnBZXishc/xBvfq7COd0J82pmB3gAyJ+igrgdg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieejgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihhtuhdrihhnthenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1398DC200A4; Fri, 19 Jul 2019 07:37:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: <6d0cfaaf-2d1d-4120-85a2-2f613d0f696c@www.fastmail.com> In-Reply-To: <9325.1563492610@localhost> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <27800.1563297174@localhost> <9325.1563492610@localhost> Date: Fri, 19 Jul 2019 12:36:45 +0100 From: "Alexey Melnikov" To: "Michael Richardson" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, "The IESG" , anima@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Anima] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-anim?= =?utf-8?q?a-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 11:37:25 -0000 On Fri, Jul 19, 2019, at 12:30 AM, Michael Richardson wrote: > > Alexey Melnikov wrote: > >> > o In the language of [RFC6125] this provides for a SERIALNUM-ID > > >> category of identifier that can be included in a certificate and > > >> therefore that can also be used for matching purposes. The > > >> SERIALNUM-ID whitelist is collated according to manufacturer trust > > >> anchor since serial numbers are not globally unique. > > > This is actually not helping. I was looking for something like: > > > DNS-ID = a subjectAltName entry of type dNSName > > > Basically I was asking for a definition of SERIALNUM-ID somewhere. > > It's a (subject)DN of serial number=123456, not a subjectAltName. > (not the CertificateSerialNumber) In this case, you need to use CN-ID as the base for the definition. The important part there is that the RDN can't be repeated multiple times in a DN. If it does, that would make the whole DN not suitable for use a la RFC 6125. > It's X.520.. via 802.1AR and RFC5280 section 4.1.2.4. > https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-201610-I!!PDF-E&type=items > section 6.2.9. > > o Client authentication is automated using Initial Device Identity > (IDevID) as per the EST certificate based client authentication. > The subject field's DN encoding MUST include the "serialNumber" > - attribute with the device's unique serial number. > + attribute with the device's unique serial number as explained in > + Section 2.3.1 > > - o This extends the informal set of "identifer type" values defined > - in [RFC6125] to include a SERIALNUM-ID category of identifier that > - can be included in a certificate and therefore that can also be > - used for matching purposes. As noted in that document this is not From nobody Fri Jul 19 06:15:20 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F012013E; Fri, 19 Jul 2019 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zqxMaLH9tSNY; Fri, 19 Jul 2019 06:15:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2238812019D; Fri, 19 Jul 2019 06:15:05 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 473CADCE7E32AC6F50AF; Fri, 19 Jul 2019 14:15:03 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Jul 2019 14:15:02 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.238]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 21:14:55 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA agenda for IETF 105 Thread-Index: AdU+M0KgwSLqNAugTbOLrP8qMt0b4A== Date: Fri, 19 Jul 2019 13:14:55 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299A1964C@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Primary ANIMA agenda for IETF 105 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 13:15:14 -0000 Hi, ANIMA,=0A= =0A= The below is the link to our primary ANIMA agenda. It is a subject to be ch= anged.=0A= =0A= https://datatracker.ietf.org/meeting/105/materials/agenda-105-anima=0A= =0A= Please no hesitate to contact the chair for any miss or mistake.=0A= =0A= Speakers, please send your slides to chairs by Sunday, July 21st, 2019. Tha= nks.=0A= =0A= Regards,=0A= =0A= Sheng=0A= From nobody Sat Jul 20 19:18:09 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CFF12006A; Sat, 20 Jul 2019 19:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1wuqOynvsIF6; Sat, 20 Jul 2019 19:18:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F9C120018; Sat, 20 Jul 2019 19:18:04 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6L2HoiE021888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Jul 2019 22:17:53 -0400 Date: Sat, 20 Jul 2019 21:17:49 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190721021748.GM23137@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <12747.1563315277@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12747.1563315277@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 02:18:07 -0000 On Tue, Jul 16, 2019 at 06:14:37PM -0400, Michael Richardson wrote: > > I have responded to DISCUSSes from: > Alissa Cooper: https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU > Roman Danyli: https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI > Alexey Melnikov https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M > Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > Eric Vyncke: https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs > > plus comments: > Mirja Kühlewind https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw > Magnus Westlund: https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE > and noted comments from Barry and Warren. > > and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the last. (You can always consult the datatracker page, too: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ I guess there's a couple No Objection with COMMENT that aren't mentioned above but maybe not that need replies.) > I'm going to use this email to deal with Ben's comments which I think we > already dealt with other edits, then I'll deal with low-hanging fruit, and > then decide how to deal with the desire for a high-level security analysis. > > Benjamin Kaduk via Datatracker wrote: > > (5) RFC7951 is cited for the audit log response, but I cannot find the > > underlying YANG module that is JSON-encoded using the RFC 7951 > > procedures. Furthermore, I don't think the "nonce" handling (with > > explicit "NULL" string where base64-encoded binary data might be > > expected) would be consistent with the 7951 rules. > > We did not resort to a YANG data model for the auditlog responses, so I spent > a few minutes mystified by your complaint... then: > We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)! Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, of course) > (Those numbers are annoyingly similar. And we actually made this mistake > before, I wonder if this was collatoral damage from a global search and replace) > > > (6) In Section 7.2: > > > The pledge can choose to accept vouchers using less secure methods. > > These methods enable offline and emergency (touch based) deployment use > > cases: > > > 1. The pledge MUST accept nonceless vouchers. This allows for a > > use > > > It's very unclear to me what this "MUST" means, especially so given > > that the entire section 7 is declared to be non-normative. Is it that > > the client "can choose" whether it "MUST accept nonceless vouchers"? > > That would seem to make the MUST basically ineffective. > > > > > > More broadly, if the entire Section 6 is non-normative, why is there > > any normative language in it? > > First, I think you mean section 7? I think you're right and that was a typo; sorry. > If so, the reason for normative language is because, we want to say, "if you > do X, then you MUST do it this way". > > Second, we have referenced some pieces of section 7.2 from section 9. > We think that there are significant security issues by accepting nonceless > vouchers, which we discuss in 11.1. A variation of the protocol is when > the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. > There could otherwise be some more complex (proprietary, or documented later > on) evaluation of whether to accept a nonceless voucher. For instance, the > MASA could sign them with a different key, perhaps one stored in an HSM. Okay, so it is that the client (well, manufacturer?) chooses whether or not to accept nonceless vouchers. So we could change the introduction to the enumerated list to be saying that this is a list of exclusive candidate behaviors that could be chosen independently of each other, and not a collection of behaviors all of which are expected to be implemented. > A key point is that the Manufacturer/MASA knows exactly the rules that the > Pledge has been coded to, and we don't need to agree on all these rules to > get interoperability. Originally, we didn't even think we needed to > standardize the voucher, just the voucher-request; but it was the desire to > audit them on the Registrar that changed our mind. > > > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > > are not registered in Section 8.1 > > Good catch, we have since been told by the .well-known designated expert that > either we create a new registry, or we just ask IANA to point the "est" > definition at RFC7030 and this document. Most .well-known entries do not > have registries. > > I haven't heard a clear opinion as to which we should do. I haven't, either, but if we do need an explicit list, we can remebmer to include these as well. > > (7.1) I think we also need to register the > > "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. > > added. > > > (8) The versioning mechanism for Pledge BRSKI Status Telemetry is > > underspecified, including the interaction with new registered values. > > This was updated based upon comments from Adam. > > > (9) The versioning mechainsm for the MASA audit log response is > > underspecified, including whether a registry of field names is > > appropriate. > > This was updated based upon comments from Adam. (I didn't get to read the other ballot positions before submitting mine, so this is great to see.) > > (10) The term PKIX seems to be incorrectly used a few times; it refers > > to the Internet PKI, and so things like a private PKI internal to a > > manufacturer would probably not be best described as such. Such > > private PKIs can of course still reuse the protocols and mechanisms > > developed for PKIX, and it's accurate to describe them as such. > > I would never call the Internet PKI "PKIX". > I'd call it WebPKI, or CAB. > PKIX is the set of IETF specifications that made X509v3 useful. > (And why I try never to use "X509"...) > > I couldn't find a reference to private PKI, so maybe I mis-understand. This document details protocols and messages to answer the above questions. It uses a TLS connection and an PKIX (X.509v3) certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer points 1 and 2. It uses a new artifact called a "voucher" that the [...] Pledge authentication and pledge voucher-request signing is via a PKIX certificate installed during the manufacturing process. This is The comment about private PKI was me making an assumption; I could be wrong. But I don't really expect all manufacturers that do this to have their IDevID signing CA be part of the Internet PKI; I expect them to be standalone CAs with the root baked into hardware and nothing else that uses that root. Does that help clarify? > > (11) In a few places we describe the voucher-request in terms of its > > YANG structure but do not say that it has to be wrapped in a signed CMS > > object as is done for the RFC 8366 voucher. > > I will review this; previous versions (prior to ~20) provided for both signed > and unsigned voucher requests, and we removed this feature. > I added some phrases to sentences in section 3: > > > - A pledge forms the "pledge voucher-request" and submits it to the > - registrar. > + A pledge forms the "pledge voucher-request", signs it with it's > + IDevID and submits it to the registrar. > > > > - The registrar in turn forms the "registrar voucher-request", and > - submits it to the MASA. > + The registrar in turn forms the "registrar voucher-request", > + signs it with it's Registrar keypair and submits it to the MASA. > Thanks. I was actually really confused about this for a while until I went back to look at 8366. > > (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the > > domainID calculation? > > What we really want is a hash of the registrar's key/cert. > We don't want to list it literally in the auditlog as it divulges too much. > We just want the RFC5280 Subject Key Identifier (4.2.1.2), but since both > the Registrar and the MASA need to calculate this value, we had to be > specific as to how it is done. If there is a better reference with better > agility, please let us know. > If the Registrar could be depended upon to always provide the extension, then > we could use the extension contents directly. It sounds like you don't want to try to require that the registrar do so, though (which would probably be fine from my point of view). I note that 5280 says "other methods of generating unique numbers are also acceptable"; even replacing SHA-1 with SHA-256 in that construction would be an improvement, from my point of view. Do we think that retaining consistency with the 5280 algorithm would (e.g.) help facilitate implementation or some other concrete benefit? I don't think that just compatibility for the sake of compatibility is a strong justification for using SHA-1 at this point. > > (13) In Section 5.5.1: > > > As described in [RFC8366] vouchers are normally short lived to avoid > > revocation issues. If the request is for a previous (expired) voucher > > using the same registrar then the request for a renewed voucher SHOULD > > be automatically authorized. The MASA has sufficient > > > I don't understand what "for a previous (expired) voucher" means. Is > > it something like "containing the same content as a previous voucher > > request for which a voucher was issued", with the presumption that the > > voucher expired before the pledge could successfully imprint, so it > > needs to try again? Or does this extend to longer timescales, like a > > device that gets deployed for a couple years and is then reset to > > factory settings and has to rebootstrap but is still by the same > > registrar? > > It is intended for both uses. > Either to be able to easily extend a short-lived voucher, or to get another > one years later. The MASA does not need to actually use the included > history; it can ignore it completely and make an entirely new decision. Hmm, okay. I still think that the grammar just doesn't like up about a "request for" a "previous voucher" means, so hopefully you can come up with some different text. I don't think I have a good enough picture to do so myself, unfortunately. > > (14) In Section 5.6: > > > The server MUST answer with a suitable 4xx > > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, > > the response data from the MASA MUST be a plaintext human- readable > > (ASCII, English) error message containing explanatory information > > describing why the request was rejected. > > > It seems hard to support this stance on internationalization in 2019. > > We don't believe that this response will go anywhere other than logs, > for software suppliers to evaluate. Localizing these error message causes > more problems in my experience than benefit. 90% of the information is in > the 4xx/5xx code. I should probably defer to my ART-area colleagues here. But you're saying that mandating English is better than allowing UTF-8 and otherwise leaving it as implementation defined? > > (15) In Section 5.9.4: > > > To indicate successful enrollment the client SHOULD re-negotiate the > > EST TLS session using the newly obtained credentials. This occurs by > > the client initiating a new TLS ClientHello message on the existing TLS > > connection. The client MAY simply close the old TLS session and start > > a new one. The server MUST support either model. > > > Is this supposed to be sending a new TLS ClientHello in the application > > data channel or as a new handshake message (aka "renegotiation")? The > > latter is not possible in TLS 1.3 and is generally disrecommended > > anyways even in TLS 1.2. I would strongly suggest to remove the > > "renegotiation" option and just leave "close the connection and start a > > new connection/handshake". > > Okay, fixed to say: > > To indicate successful enrollment the client SHOULD re-negotiate > the EST TLS session using the newly obtained credentials. This > - occurs by the client initiating a new TLS ClientHello message on the > - existing TLS connection. The client MAY simply close the old TLS > - session and start a new one. The server MUST support either > + occurs by the client closing the existing TLS connection, and > + starting a new one. The server MUST support either > model. I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably good enough to clear the discuss. > > Appendix C > > > I don't know how important file "ietf-mud-extension@2018-02-14.yang" > > is, but it seems a tad generic. > > I changed ietf-mud-extension to ietf-mud-brski-masaurl-extension. > > > Appendix D > > > [Just checking that Michael wants sandelman.ca embedded in the final > > RFC] > > I don't have a problem with it. There is an error: > 3726:d=9 hl=2 l= 55 prim: UTF8STRING :# > where a variable name rather than it's value went into a certificate, and I > will probably re-run it again before AUTH48. We haven't gotten 100% > interoperability proven yet inside FairHair Alliance, so I can't be sure it's > all correct. Okay, that sounds fine to me. > I'll stop here, and continue in a new email. Sure; more smaller mails is probably easier all around. -Ben From nobody Sun Jul 21 19:51:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105DB120096 for ; Sun, 21 Jul 2019 19:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3UBkQRS2WXbE for ; Sun, 21 Jul 2019 19:51:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60F1120033 for ; Sun, 21 Jul 2019 19:51:36 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:1232:144:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id BDDEA1F44B; Mon, 22 Jul 2019 02:51:34 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D9C332025; Sun, 21 Jul 2019 22:51:54 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: anima@ietf.org In-reply-to: <37592AA0-87AB-4036-93A9-B60F56539F53@tzi.org> References: <6535.1560786935@dooku.sandelman.ca> <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de> <17732.1563383448@localhost> <37592AA0-87AB-4036-93A9-B60F56539F53@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Wed, 17 Jul 2019 23:55:16 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 21 Jul 2019 22:51:54 -0400 Message-ID: <12491.1563763914@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 02:51:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On Jul 17, 2019, at 19:10, Michael Richardson > wrote: >>=20 >> always base64 the payloads > Which means that the content-type headers lie. Backwards > combyativbility [actual autocorrect result :-)] can be nasty. But > sniffing this out should be easy. You are saying that the Content-Type: application/pkcs* claims are incorrect, because the payloads have been base64 encoded. This would be quite normal had these payloads been carried in email (which does happen) but then there would have been a useful CTE header to clarify the encoding. I agree that it's definitely inconsistent, and this is why I think it's not enough for it to just remain as errata. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl01JMoACgkQlUzhVv38 QpCsCwf/TsgjjLRzXFdjy39i87yaXvg8GddyF88oiv3p3Uxoi1AliGmO7mdbpJJq gfK/K/QQ5fvsF75C9rcNsroLlsSXLP9wD5FPj6NtTrlqQhcNyrkeMWMb79RpCpGT 5oO8vXPKwjghLN6cbOR5U1fKeWuNEvyl3+1ygvSLZXPLsgULYeQOgw5B2BpIGH7L 6W5RweSJaLiqp57C6le2VXIaa8R9OI+uMUt30eibk4EPNm68zts3F7V9SfQvElKm 2Br0ebVCRiasB+X2K9aaq2ql500YBvB9XOkwCNt+5ctEQoqLs3E7V3kXCZy7vYlN sIJaDCUNn5EEU3YZbkuKo1KwK8gUtg== =883R -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 22 05:30:37 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CBA12027D; Mon, 22 Jul 2019 05:30:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156379862980.28103.9193282705891897433@ietfa.amsl.com> Date: Mon, 22 Jul 2019 05:30:29 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-23.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:30:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-23.txt Pages : 97 Date : 2019-07-22 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-23 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-23 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 05:49:47 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52866120299; Mon, 22 Jul 2019 05:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156379977524.28045.3324190529964988265@ietfa.amsl.com> Date: Mon, 22 Jul 2019 05:49:35 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-24.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:49:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-24.txt Pages : 98 Date : 2019-07-22 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-24 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-24 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 06:00:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C825E12011D for ; Mon, 22 Jul 2019 06:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6opjFbPcfB5V for ; Mon, 22 Jul 2019 06:00:35 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315C412001A for ; Mon, 22 Jul 2019 06:00:34 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-9cab.meeting.ietf.org [31.133.156.171]) by relay.sandelman.ca (Postfix) with ESMTPS id 3C0881F44B for ; Mon, 22 Jul 2019 13:00:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 86CCB13CB; Mon, 22 Jul 2019 09:00:54 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-reply-to: <156379977524.28045.3324190529964988265@ietfa.amsl.com> References: <156379977524.28045.3324190529964988265@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Mon, 22 Jul 2019 05:49:35 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 22 Jul 2019 09:00:54 -0400 Message-ID: <6567.1563800454@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-24.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:00:37 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have posted two versions of BRSKI this morning. This is intentional!! I had posted a diff URL against the github copy that was the current state = of responding to the IESG DISCUSS. One of the fixes is for a very long line example in the appendix. The result is that the diff is very wide and hard to read. I have uploaded -23, which is identical to -22, but has the long line wrapped. You can see it here: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-bootstrapping-keyinf= ra-23 I have uploaded -24, which has all the changes made, and you can see it here: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-bootstrapping-keyinf= ra-24 There are still two significant bits of DISCUSS that I have yet to deal wit= h. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl01s4UACgkQlUzhVv38 QpCX1gf9H7cQQ3FYAyYj7S3gPxPvJEH9R/ltSvDWzjebkzpB2dRN2SgPpwNvlKzx srKob9eN9wVKyxjdHlPTv3CPTlZ5RIwcQoJItILnpK9XU3OOviOFxwrUSnpe9WKv 16ViXS8xloqi/n+udWWg5ODNhnRv3Cr+Nefu47gMamob32JGrNO8xpjmsw9z109X xRX0GEZWNZCh6KfmAej1LB2taQ2CQ070C9aFjAqCGx4lVDryedo7PXQMDqrUMIG8 2foFKfQTcOu2Gu7laeq1wImiB02Z5EIr1TpvfN22iA/RsDBeI13bn1xaLYwnzSKv Vo+dFiQzVZT809q2to619W6lA1arKw== =xaE5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 22 15:15:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C67120143; Mon, 22 Jul 2019 15:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J-e-neCn-vvX; Mon, 22 Jul 2019 15:15:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDA71202F4; Mon, 22 Jul 2019 15:15:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 586E654806F; Tue, 23 Jul 2019 00:15:18 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 49D3E440041; Tue, 23 Jul 2019 00:15:18 +0200 (CEST) Date: Tue, 23 Jul 2019 00:15:18 +0200 From: Toerless Eckert To: Alissa Cooper Cc: Sheng Jiang , "ibagdona@gmail.com" , "anima-chairs@ietf.org" , IESG , "anima@ietf.org" Message-ID: <20190722221518.gjkqh3gnr7rfua2y@faui48f.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B9299A0DDCE@NKGEML515-MBS.china.huawei.com> <228BD1A3-4612-43F6-B26C-12DB736775F9@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <228BD1A3-4612-43F6-B26C-12DB736775F9@cooperw.in> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Alissa: Re: Reminder//RE: Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:15:39 -0000 Hi Alissa, Ignas did upload wiki version 2.0.9 to data-tracker today, where it is online now as versions charter-ietf-anima-01-07. Would be great if you can deal with your block, so we can at least show some measure of progress on our progress in the process during the WG meeting. Thanks so much Toerless On Tue, Jul 16, 2019 at 09:44:53AM -0400, Alissa Cooper wrote: > Thanks. I???ll clear my block when the 2.0.9 version gets uploaded to the datatracker. > Alissa > > > On Jul 16, 2019, at 5:30 AM, Sheng Jiang wrote: > > > > Dear Alissa, > > > > Could you check whether the latest 2.0.9 version on WiKi addresses your block. If not, we would like to further modify it according to your new feedback. We really would like to see progress on rechartering. Many thanks. > > > > https://trac.ietf.org/trac/anima/wiki/Recharter2019 > > > > Dear Ignas, could you upload the 2.0.9 version to datatracker? Many thanks, > > > > Sheng > > > >> -----Original Message----- > >> From: Toerless Eckert [mailto:tte@cs.fau.de] > >> Sent: Wednesday, July 10, 2019 7:34 PM > >> To: Alissa Cooper ; ibagdona@gmail.com > >> Cc: Sheng Jiang ; Brian E Carpenter > >> ; IESG ; anima-chairs@ietf.org; > >> anima@ietf.org > >> Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with > >> BLOCK and COMMENT) > >> > >> Thanks for the update, Sheng! > >> Ignas: can you pls. upload wiki 2.0.9 charter to datatracker ? > >> > >> Alissa: Thanks for your comments. I hope that the latest 2.0.9 version on the wiki > >> as proposed by Sheng resolves your block. If not, then it would be great if we > >> could accelerate resolving them so that we could actually start working on charter > >> 2 @ IETF105. > >> > >> I think we always intended for what you proposed to be true, e.g: that whats not > >> listed in the target work areas would require AD approval to be chartered. I guess > >> we never wrote that explicitly because we had some even more specific > >> mentioning of explicit AD approval cases in earlier versions of the proposed > >> charter and those sentence got argued away by reviewers as being too > >> procedural and unnecessary for a charter. > >> > >> Cheers > >> Toerless > >> > >> On Mon, Jul 08, 2019 at 09:23:01AM -0400, Alissa Cooper wrote: > >>> Hi Sheng, > >>> > >>>> On Jul 3, 2019, at 10:39 AM, Sheng Jiang wrote: > >>>> > >>>> Hi, Alissa, > >>>> > >>>> Thanks for your kindly response. I have made a new version (2.0.8) according > >> to your feedback. Explanation in lines below. > >>>> > >>>> Please see https://trac.ietf.org/trac/anima/wiki/Recharter2019 > >>>> > >>>>> -----Original Message----- > >>>>> From: Alissa Cooper [mailto:alissa@cooperw.in] > >>>>> Sent: Wednesday, July 3, 2019 5:13 AM > >>>>> To: Brian E Carpenter > >>>>> Cc: IESG ; anima-chairs@ietf.org; anima@ietf.org > >>>>> Subject: Re: [Anima] Alissa Cooper's Block on > >>>>> charter-ietf-anima-01-05: (with BLOCK and COMMENT) > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I???ve been discussing this on my weekly call with the OPS ADs for > >>>>> the last couple of weeks and based on the call that we had earlier > >>>>> today my understanding is that now would be a good time to re-review. > >>>>> > >>>>> Regarding this text: "New work items will be adopted by the WG only > >>>>> if their contributors target them to enter WG last call within a > >>>>> number of IETF meeting cycles agreed by the AD.??? > >>>>> > >>>>> I still don???t get this. It is a very common case that > >>>>> contributors think their drafts are going to get through to WGLC in > >>>>> X cycles, and then they end up taking 2X or 10X because some new > >>>>> person wanders into the WG or some other work starts up in another > >>>>> WG that has an intersection with the work or someone changes jobs > >>>>> or any manner of other things. The WG needs milestones with dates, > >> preferably at the point of approving the re-charter. > >>>>> Those might be missed too, but there might as well not be two sets > >>>>> of markers laid down that are potentially going to be missed rather than one > >> set. > >>>> > >>>> I have just deleted the sentence. It's something the chairs can do during the > >> WG management process. We tried to give draft owners some pressure not to > >> be too slow by adding these text. I do agree this should not be so rigid as these > >> text. So, let's take it out and the chairs will monitor the progress of WG drafts > >> closely. > >>> > >>> Thanks. > >>> > >>>> > >>>>> Regarding the ???indicative scope of possible work items??? ??? > >>>>> this doesn???t address my concern about the WG???s scope. This > >>>>> charter is in contrast to the current ANIMA charter, which says: > >>>>> "The initial set of work items is limited to the above list to stay > >>>>> focused and avoid 'boiling the ocean???.??? I don???t see the > >>>>> rationale for not carrying that forward to the next set of specific > >>>>> work items where WG participants have demonstrated interest and > >>>>> intent to carry the work forward. If that is the list of initial milestone topics > >> listed, then limiting to that makes sense to me. > >>>> > >>>> I have added a specific list of work items into the initial milestone list. > >>>> > >>>> Obviously, this initial milestone list does NOT cover all the topics > >>>> that WG participants have showed interests and willingness to work > >>>> on. The purpose to have this description of "indicative scope of > >>>> possible work items??? are actually two: A, limit the potential work > >>>> items not to be too wide > >>> > >>> I think my disconnect here is that the list doesn???t actually limit the WG???s > >> scope because it uses the language ???indicative scope of possible work items??? > >> and ???including but not limited to.??? The five areas of work in this list seem > >> broad and large enough to keep the WG busy for quite some time. For the > >> charter to effectively limit the scope I think it would need to say ???The scope of > >> work items is limited to:??? or something like that. > >>> > >>> Thanks, > >>> Alissa > >>> > >>>> , otherwise, people may take anything has the work "automatic" to the WG; B, > >> to give the chairs a little bit flexibility to adopt new works beyond the initial > >> milestone list. We try to avoid the problem that every time a new draft comes up, > >> it may become a charter revision, particularly, giving the current re-charting > >> process have taken us many months. > >>>> > >>>> Best regards, > >>>> > >>>> Sheng > >>>> > >>>>> Thanks, > >>>>> Alissa > >>>>> > >>>>>> On Jun 10, 2019, at 9:02 PM, Brian E Carpenter > >>>>> wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I've taken the liberty of posting an update to the draft charter > >>>>>> at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried to > >>>>>> respond to all the IESG comments, and in particular: > >>>>>> > >>>>>> (a) I deleted Intent from the summarised reference model > >>>>>> framework, since the reference model doesn't usefully define Intent. > >>>>>> > >>>>>> (b) I tried to make the statement about workload throttling more > >>>>>> implementable. > >>>>>> > >>>>>> (c) I still think that the laundry list of *possible* work items > >>>>>> is useful (it helps to define the scope) but I've tried make it > >>>>>> clear that it is only the "indicative scope of possible work items". > >>>>>> It really isn't mission creep; all the items mentioned relate > >>>>>> directly to the ANI and AF topics. > >>>>>> > >>>>>> (d) I intentionally removed the reference to not covering machine > >>>>>> learning and AI. It isn't suggested anywhere in the reference > >>>>>> model, so why even mention it? > >>>>>> > >>>>>> (e) I fixed nits and tuned the wording in several places. > >>>>>> > >>>>>> I hope this helps. We really need a new charter before Montreal. > >>>>>> WG Chairs and AD, over to you... > >>>>>> > >>>>>> Regards > >>>>>> Brian Carpenter > >>>>>> > >>>>>> On 02-May-19 08:39, Brian E Carpenter wrote: > >>>>>>> Hi Alissa, > >>>>>>> > >>>>>>> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: > >>>>>>> ... > >>>>>>>> ---------------------------------------------------------------- > >>>>>>>> ---- > >>>>>>>> -- > >>>>>>>> BLOCK: > >>>>>>>> ---------------------------------------------------------------- > >>>>>>>> ---- > >>>>>>>> -- > >>>>>>>> > >>>>>>>> (1) "Acceptance of work items by the WG will be > >>>>>>>> scheduled/throttled so that contributors can target them to > >>>>>>>> enter WG last call after not more than a number of IETF meeting cycles > >> agreed by the AD." > >>>>>>>> > >>>>>>>> I don't understand the implications of this. What happens if the > >>>>>>>> adopted work items have not entered WGLC after the agreed number > >>>>>>>> of cycles? If the answer is anything other than "the WG abandons > >>>>>>>> the work," I don't understand how this is a throttling > >>>>>>>> mechanism. A throttling mechanism would need an explicit limit > >>>>>>>> on the number of > >>>>> adopted work items at any one time, I think. > >>>>>>> > >>>>>>> I agree that the text is a bit illogical. In a sense it's > >>>>>>> unnecessary, because every WG should be matching its workload to > >>>>>>> its capacity. Maybe that's all we should say, rather than trying > >>>>>>> to describe a > >>>>> slightly vague algorithm? > >>>>>>> > >>>>>>>> (2) The proposed work items is a very large and somewhat > >>>>>>>> unbounded list of items, whereas the purpose of writing a > >>>>>>>> charter is to scope the work of the WG and hopefully set out a > >>>>>>>> realistic work plan that will be accompanied by deployment. For > >>>>>>>> a WG that has produced 5 documents in the last 5 years, I think > >>>>>>>> the charter needs to more narrowly focus on the most highly > >>>>>>>> prioritized work items. Once those are nearing completion, it > >>>>>>>> seems as though evaluation of what is needed next based on > >>>>>>>> deployment experience would then dictate the next > >>>>> set of items for another re-charter. > >>>>>>> > >>>>>>> I think the point here is that now that the relatively small > >>>>>>> number of infrastructure documents are almost finished, the next > >>>>>>> stage opens up the possibilities for a much wider range of work > >>>>>>> that builds on the infrastructure. The priorities aren't even > >>>>>>> obvious. So this goes with the previous point, and to quite some > >>>>>>> extent the criteria will be whether the WG has capacity more than which > >> topic has priority. > >>>>>>> > >>>>>>> That's why there's a bucket list of work items and a short list > >>>>>>> of immediate milestones. > >>>>>>> > >>>>>>> Would this help? > >>>>>>> > >>>>>>> s/Proposed work items include.../Possible work items include.../ > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ---------------------------------------------------------------- > >>>>>>>> ---- > >>>>>>>> -- > >>>>>>>> COMMENT: > >>>>>>>> ---------------------------------------------------------------- > >>>>>>>> ---- > >>>>>>>> -- > >>>>>>>> > >>>>>>>> It would be good to see milestones with dates before this gets > >> approved. > >>>>>>>> > >>>>>>>> I think this charter would benefit from an English edit pass > >>>>>>>> before going > >>>>> out for external review. > >>>>>>> > >>>>>>> I'll volunteer, when the open issues have been resolved. > >>>>>>> > >>>>>>>> What is "compounding environment"? > >>>>>>> > >>>>>>> An excellent question. > >>>>>>> > >>>>>>> Brian > >>>>>>> > >>>> > >> > >> -- > >> --- > >> tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 22 15:31:58 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A1E12006B; Mon, 22 Jul 2019 15:31:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: anima-chairs@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156383470887.22833.11109672409194625502.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2019 15:31:48 -0700 Archived-At: Subject: [Anima] Alissa Cooper's No Objection on charter-ietf-anima-01-07: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:31:49 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-anima-01-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-anima/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks you for addressing my BLOCK and comments. From nobody Mon Jul 22 16:17:32 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EB9120048; Mon, 22 Jul 2019 16:17:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156383744423.22833.17758555084448760826@ietfa.amsl.com> Date: Mon, 22 Jul 2019 16:17:24 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-20.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:17:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-20.txt Pages : 163 Date : 2019-07-22 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-20 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 22 16:20:47 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A71200B9; Mon, 22 Jul 2019 16:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mLC8rX_8aZ_E; Mon, 22 Jul 2019 16:20:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FBC120048; Mon, 22 Jul 2019 16:20:38 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 208D4548002; Tue, 23 Jul 2019 01:20:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 09EF9440041; Tue, 23 Jul 2019 01:20:32 +0200 (CEST) Date: Tue, 23 Jul 2019 01:20:31 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190722232031.bk3uiks2zvxegdwc@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190716223545.GB58520@kduck.mit.edu> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:20:44 -0000 --- Context: I hope i am correctly restating, that this reply is as follows: -> Ben reviewed -16, i posted reply into -19, then Ben created a second email reply, and this email is the reply to that second reply from me with the changes put into -20 that i just posted. -> The diff for the changes discussed in this email is: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.1.txt They are also summarized under section (1) of the -20 changelog. -> The total changes -19 to -20 are of course: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt -- Start of reply: Ben: Thanks a lot! Inline. Deleted all sections where i couldn't write anything but "thanks, ok, .. or the like" (and didn't have to do any fixes). On Tue, Jul 16, 2019 at 05:35:47PM -0500, Benjamin Kaduk wrote: > Thanks for the updates. I'm sorry it took so long to get feedback on them > -- it took me a while to get a free day to review the whole document while > I've been moving across the country and with my family's schedule. No worries. I still caused more delay over the years, so when Brian Carpenter should start to chase down who is responsible for his GRASP hanging in RFC editor queue forever, you can hide behind me. > > Aka: We wanted to use a field where we know every implementation supports > > but that is also not conflicting with other pre-existing uses. > > We did not want to rely on additional ASN.1 parsing of its content, because > > embedded implementations might have fixed parsers. Thats why we choose a > > a simple non-ASN.1 encoding of a field we know is always supported but > > never used for actual network functionality so it can not conflict. And > > if anything else uses already this field, you would actually see emails > > to an address because the format we choose is a working rfc822name > > I still feel like this is not the best architectural choice. Later on you > ask for some guidance on what the ASN.1 structure for an otherName solution > would/could look like; I'll include that in my updated ballot position's > Comment section. Sure. there is a list of several bullet points in favor of the current encoding in section 6.1.1. It would be good to see arguments explaining why a pure ASN.1 option is better. I can repeat those points as question in an appropriate thread about the updated ballot position and how it addresses these bullet points. > > > In a few places, the MTI cryptographic mechanisms are under-specified, > > > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > > > to note these locations in my section-by-section comments. > > > > Thanks. See below. Should also have been fixed through Erics review. > > There seem to be a tweak or two left (though to be honest I will need to > consult someone more knowledgable in IKEv2 than me). See below in comments section, it was a good trigger to hopefully significantly improve the text for -20. > > > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > > > root, but if I understand correctly the RPL root is automatically > > > determined within the ACP, and thus the operator does not a priori know > > > which node will become the RPL root. Am I misunderstanding, or is this > > > effectively placing this requirement on all ACP nodes? > > > > More or less, yes. Packet counter on the default route to a null interface for example, > > maybe a HW register for the last thus discarded packets destination address, > > allowing at least sampling of such addresses. Thats what i was thinking > > of suggesting if i ever manage to move on from this spec to the YANG model for > > the ACP. > > > > I am sure we could reduce requirements by differentiating between nodes > > that should never become root, but that would lead to even more text > > lamenting about ad-hoc type of ACP setups. Besides, its a SHOULD and even > > low-end IoT devices using CPU forwarding would have no issue implementing this. > > I agree with the assessment of low likelihood of actual problems, but would > appreciate a brief note in the text. Added the following override and explnation: As this requirement raises additional data plane requirements, it does not apply to nodes where the administrative parameter to become root () can always only be 0b001, e.g.: the node does not support explicit configuration to be root, or to be ACP registrar or to have ACP-connect functionality. If an ACP network is degraded to the point where there are no nodes that could be configured roots, ACP registrars or ACP-connect nodes, traffic to unknown destinations could not be diagnosed, but in the absence of any intelligent nodes supporting other than 0b001 administrative preference, there is likely also no diagnostic function possible. > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > I think it's a big help! If I were going to change anything, I might add a > note about how preexisting NMSes will need ACP-connect until such time as > there is a single device that is ACP-native and also exposes a non-ACP > admin interface to any relevant ACP functionality. But that assumes that I > understand the current and desired future state of affairs, which I am not > fully confident is correct. Changed existing bullet point to be more explicit about these details: When non-ACP capable nodes such pre-existing NMS need to be physcially connected to the ACP, the ACP node to which they attach to needs to be configured with ACP-connect according to . It is also possible to use that single physcial connection to connect both to ACP and the data-plane of the network as explained in . > > hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" > > > > DIGIT was predefined ABNF, couldn't find any hex, didn't find a > > reason why case insensitivity would be a lot of help here... > > If I'm reading https://tools.ietf.org/html/rfc5234#section-2.3 properly you > have to go for %d97 etc. to get case-sensitivity; RFC 7405 adds the %s > extension that is more readable. There is no real intention to be case sensitive or insensitive. We originally had lowercase when we started with standard IPv6 string encoding address format, but the ":" required do not fit the local address part of rfc1034, so now there is really no reason to use lowercase hex-characters. So, i simplified the ABNF to use HEXDIG (upper case) and adjusted the example accordingly. > > As said: If it was me, i would still prefer to not use ASN.1 for the > > internal encoding due to risk of non-extensibility of existing low-end > > parsers and more limited diagnostic to humans. > > As mentioned above, I put some more thoughts on this in my new ballot > position. We should probably fork off a new subthread for the rfc822Name > vs. otherName question. ok. > > We had a pretty broad discussion asking folks if they where aware of > > email addresses in certificates of network devices ever being used > > for something automatically (aka: not through visual inspection by a human), > > and nobody had an example. Thats why we felt it was quite safe to choose > > the rfc822 format. The use of "+" then was just opportunistically using > > what might be the best use of existing practices, but without expecation > > that this would actually be ever used. > > We do occasionally publish documents that change the semantics or > expectations around existing fields after such analyses, but AFAIK we > always include the justification and summary of research in the document > doing so, along with calling out that there is a change. Ok. If that observation was a hint for me to add text, i didn't get it, but we can disuss in the forked-of thread. > > > Is this supposed to be an exact byte-for-byte match, or is some form of > > > insensivity allowed that would require normalization/canonicalization prior > > > to comparison? > > > > Added "(lowercase normalized)" to the comparison requirement for the acp-domain-name. > > Does this imply A-labels (RFC 5890)? No. Added the following explanation: To keep the encoding simple, there is no consideration for internationalized acp-domain-names. The ACP domain information is not intended for enduser consumption, and not an element of inter-operator security, but purely as a hash seed for ULA prefixes and for operator diagnostics. Any operator owning only an internationalized domain name simply needs to pick an equivalently unique 7-bit ASCII acp-domain-name string. While i admire all the internationalization work for end users, i hope i am well representing operator preferences to not be bothered with that complexities within their operational user interfaces unless really necessary. > > > Section 6.1.3.1 [...] > It looks like I wanted a few things changed/clarified: > > - the hardcoded loop-count of 255 with comment "recommended" seems jarring; > "automated detection not possible" or something similar to what you write > above might be more helpful changed to: loop-count = 255 ; recommended because there is not mechanism ; to discover network diameter. > - "Not used (yet)" is also a bit informal; "reserved for future extensions" > might be more typical ack. > - I wasn't sure if we needed to call out 'initiator' and 'ttl' specifically > as being used unchanged from another ref (assuming that ttl and > loop-count are different). added: ; see example above and explanation below ; for initiator and ttl > > > Using both "[t]he objective value" and an "objective-value" field for > > > different things is needlessly confusing; can the body text be clarified > > > somewhat about the value "SRV.est"? > > > > That was a bug on my behalf. SRV.est is called the objective name in GRASP. > > Fixed. > > > > > Can "negligbile traffic" be quantified? > > > > No. Its in the eye of the beholder (network admin). 30...60 seconds is used > > in all typical protocols i remember and will be fine for all non-low bitrate > > networks. Once you get into lower bitrates (below 1 Mbps ?) i would expect > > operators may find 30...60 seconds not negligible. > > I see this question is still coming up in the BRSKI balloting, but I don't > think I myself have more to say on the subject. We had >> 10 years in which a lot of multicast info was flooded across enterprise networks with SAP/SDP, and that only failed when endusers injected too much of such information. But in the case of ACP this can not be user but only operator controlled devices injected. So from that experience i feel very safe for the ACP use-case. [ There is always the solution of self-adjusting the rate of flooded information like in RTCP-RR, but given how we never felt that to be necessary in SAP/SDP, i am sure i won't have to hold my breath for this to become an issue in GRASP. It would be a lovely option to add, but its a generic GRASP issue, so better done as a simple GRASP extension draft. And of course it could be more fancy than RTCP-RR by figuring out the slowest network links and hence adjusting the rate for that ;-))] > > Aka: this is more about mutual agreement of two domains to trust each other > > and coming up with appropriate means to share trust anchor (aka: not easy). > > I'm still kind of unclear about Intent and how baked it is (see new ballot > text) ... Me too, but the point of the ACP document as of >= -19 is that it shouldn't depend on intent at all, so this question should not stand in the way of the ACP to become RFC. The only significant mentioning of Intent is in A.8 with the goal to emphasize the ACP specific issue that there can be circular dependencies between Intent being applied to the ACP and the ACP distributing that Intent. And the goal of that is of course that future work on Intent should be done in such a way that this circular dependency can accordingly be resolved so that ACP policy can be built on Intent. > > If you don't mind elaborate about public list, i am interested if > > that would be a simpler solution. > > ... but the public suffix list is a hack in the web community to avoid > over-coalescing for things like cookie storage: https://publicsuffix.org/ > I don't think anyone's particularly happy that it exists, but the > alternatives we know about (including not having it) are worse. Maybe i was unclear: I had no idea what the public suffix list was. Through your URL i read up and now i am marvelled and confused about all these browser use-cases, but wrt to ACP: The text you pointed to in 6.4 is now in A.8. I think there is no relationship to the public suffix list. The Intent to form a common ACP domain across the different domains in the example in A.8 is purely a local operator decision (or a decision of a few federated operators), there wouldn't shouldn't be a need for any global knowledge. Hope A.8 explains this better, if not, let me know. > > Let me know if there are any other forgotten parameters. Sugggestest > > MTI choice highly welcome. Guidance is simply the currently likely > > most widely HW accelerated supported option meeting common security > > level expectations (yes i know thats hard to quantify). > > I think we should probably check with an IKEv2 expert. Can you set that up or tell me how i would find one ? > In general I'd > expect referring to specific codepoints from > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml to > be more reliable than just textual descriptions. So, when trying to figure out how to do this, i stumbled across RFC8221 and RFC8247. I had asked Eric eternities for good IPsec/IKEv2 requirements RFC, but maybe that was even before these where published ;-) Maybe the authors would be on the shortlist of suspects to ask for review. I created a more comprehensive requirements text against native IP, but then cut down on the duplication of text for GRE/IPsec, just referring to the native IPsec text and only pointing out differences. Here is the IPsec text: An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2 for tunnel mode and IPsec/IKE signaling according for IPv6 payload (e.g.: ESP next header of 41). It MUST use local and peer link-local IPv6 addresses for encapsulation. IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode, it would only be possible to send packets originated by the ACP node itself. IPsec MUST use ESP with ENCR_AES_GCM_16 () due to its higher performance over ENCR_AES_CBC. ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carryin g legacy management protocol traffics as well as hop-by-hop GRASP). These IPsec requirements are derived from but limited to the minimum necessary options because ACP is not a general purpose use case today with a wide range of interoperability requirements against legacy devices. Once there a re updates to , these should accordingly be reflected in updates to these ACP requirements (for example if ENCR_AES_GCM_16 is superceeded in the future). Additional requirements from MAY be used for ACP ch annels as long as they do not result in a reduction of security over the above MTI requirements. For example, ESP compression M AY be used. IKEv2 MUST follow as necessary to support the above listed IPsec requirements. And here the IPsec/GRE text: The requirements for ESP/IPsec/IKEv2 are the same as for native IPsec (see ) except that IPsec transport mode and next protocol GRE (47) are to be negotiated. Tunnel mode is not required because of GRE. If IKEv2 initiator and responder support IPsec over GRE, it will be preferred over native IPsec. The ACP IPv6 traffic has to be carried across GRE according to . > > All ACP nodes supporting DTLS as a secure channel protocol MUST > > adhere to the DTLS implementation recommendations and security considerations of except with respect to the DTLS version. ACP nodes supporting DTLS MUST implement only DTLS 1.2 or later. For example, implementing DTLS-1.3 () is also an option. > > I think there was still somewhere that talked about TLS encryption/ciphers > specifically (and not as ciphersuite codepoints). Especially if you > reference it as BCP195, omitting any specific ciphersuite/etc. values from > this document is fine. Ok. Changed reference to use BCP 195 name. > > TBD: Could you recommend a good equivalent to rfc7525 to refer to for a > > good TLS 1.2 profile that i could refer to > > I think I'm confused; why is 7525 itself not usable? Because Toerless completely overlooked that 7525 not only covers DTLS but also TLS *sigh*. Changed text to: GRASP unicast messages inside the ACP are transported via TLS according to execept that only TLS version 1.2 () or higher MUST be used because there is no need for backward compatibility in the new use-case of ACP. I hope i do not have to come up with additional constraints to limit implementation complexity, but given how software-only implementation should suffice in this case (It's just for GRASP), i am not too worried before we try to attack more than opportunistically constrained devices. > > When an ACP Edge node receives a packet from an ACP connect interface, it > > MUST only forward it into the ACP if it has an IPv6 source address from that interface. > > This is sometimes called "RPF filtering". > > > > (somehow i can't shorten it, but hopefully its easier to read). > > It is (even though "it" is used for both the packet and the edge node), > thanks. Thanks. Replaced the "it". > > Thought we only do this the first time we encounter ? > > Up in the GRASP objective section. > > Whoops, that was too far ago for me to have remembered. You're right. Wonder if RFC editors have tools for this. Hope they do. > > > Merging two networks with different trust anchors requires the trust > > > anchors to mutually trust each other (for example, by cross-signing). > > > As long as the domain names are different, the addressing will not > > > overlap (see Section 6.10). > > > > > > Subject to the risk of a 40-bit collision in SHA256! While not necessarily > > > a critical flaw at this time, the limitation should probably be mentioned. > > > > Right. Added: except for the low probability of a 40-bit hash collision in SHA256. > > The current wording "As long as the routing-subdomain hashes are > different, the addressing will not overlap, except for the low probability > of a 40-bit hash collision in SHA256" takes a bit of work to tease apart. > It's not technically incorrect (the hashes can be different but share a > 40-bit initial prefix), but readers might take "routing-subdomain hashes" > to mean the post-truncation hash, in which case we might want to s/except > for the low probability/which only happens in the unlikely event/. Thanks, fixed. > > Yes, typo. IDevID was meant. The voucher RFC defined a MASA URL option. > > Fixed. > > I think you fixed a different instance than I quoted (so it's duplicated > in my new ballot comments). Eventually between the two of us we'll catch > them all, right? Yepp. Found two more LDevID that where meant to be IDevID and fixed. > 10.3.x specifically feels less-baked than the rest of 10, to me, but I'm > not going to insist on changes here. Not sure how i could bake it better, but it would probably not be worth it in this document, given how this is mostly food for thought not impacting interoperability and standardization would only come through implementation and deployment experimentation followed by some Yang model. Other reviewers (Joel if i remember correctly) where grumbling, but couldn't provide any better suggestions of how to make operator level interface shutdowns more resilient against unintential network disconnect. Hence i argued strongly to keep this section in there as important food for thought, especially because its been the #1 ask against ACP to figure out by operators i talked to. > > > Section 10.3.7 > > > > > > The control names indicated within double quotes are mostly incomplete > > > references; it seems better to say, e.g., """the "up-if-only" option for > > > node-level ACP/ANI enablement""". > > > > Not sure i completely understood what you meant. Pls. check. > > I think I was concerned about: > > If the option "up-if-only" is not selected, interfaces enabled for > ACP/ANI interpret "down" state as "admin down" and not "physical > down". In "admin-down" all non-ACP/ANI packets are filtered, but the > physical layer is kept running to permit ACP/ANI to operate. > > since I was confused about what scope "up-if-only" applied to. (But I was > somewhat generally confused when reading this section, and it may have just > been my fault and not the document's.) If your comment is about how to syntactically represent whats being written better than with "", then pls. make explicit recommendations. Otherwise i would just wait for RFC editor to hit me over the head if they don't like this. Its just that unlike all the other formal languages, we do not have anything formal for CLI, so i was using how it typically could look in descriptions of operator CLI documentation (which often have also bold and italic, which to the best of my knowledge we're missing in RFC format, so i had to be creative). It probably is a bit lazy, but waiting for RFC editor is IMHO appropriate here because they would better be able to suggest all formatting tricks i may not have thought of. If its about technical: The technical idea of "if-up-only" was to bring in another up/down level into the operator interface (CLI, Yang). Normally you have something like two levels, physically up/down and protocol level up/down. Operators often use physcially down because they want to bring down all protocols at once on an interface (e.g.: IPv4, IPv6, L2 briding, whatever). So to avoid that that commonly used command disconnects the operator itself when its managing the device remotely, the semantic of that "down" needs to be changed to what i call "admin down", which is basically bringing down everything except for ACP. So if the operator really wants to physcially disconnect himself, he has to issue a new command (physcial down), which makes it a lot more unlikely to happen unintentional. > > Let me explain how us authors cam up with that statement. > > Here is how simple/autonomic ANI (ACP+BRSKI) can be with existing spec alone: > > > > | -> Select an ANI server-router. > > | Configure "autonomic-network-server " > > | "autonomic-connect ethernet 1/1" > > | > > | -> Plug together a network of greenfield routers (no config, fresh from factory) > > | BRSKI bootstraps all routers, ACP comes up. No data-plane whatsoever. > > | > > | -> Connect management station to server-router ethernet 1/1 > > | Manage / provision network through ACP using ssh/netconf/whatever > > | > > | Under the hood, server-router config simply creates an autonomic registrar > > | and a CA with self-signed root cert, allocates ULA prefix from domain-name, > > | an registers any greenfield devices registering. Then these devices > > | hop-by-hop create ACP. > > | > > | The CLI of a commercial ANI implementation is very similar and as simple. > > > > Does this give you a better sense of the reasoning behing the statement made ? > > I think my confusion is mostly about how tightly the "server-router" is > integrated with the ACP and ANI. My mental model has existing > off-the-shelf NMSes that are not tightly integrated, so you need > ACP-connect to inject (e.g.) registrar and CA configuration into the ACP. > But your description makes it sound more tightly integrated already than I > expected. Right. Thats a different packaging option which could also be equally painless, but requires more GRASP service discovery extensions, which are drafts i am trying to get back to once ACP rolls downhill to RFC editor. I also didn't want to write too much about packaging options because it a) It is IMHO not really something that belongs int this doc (co-packaging of different functions). c) I am sure implementors in vendors will know how to read user documentation for existing pre-standard implementations that describe the above mentioned packaging for example. b) There are a lot of packaging variations, and who am i to know what for a particular vendors product line is the best. Thanks a lot for this very thorough review. From nobody Mon Jul 22 16:21:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91158120094; Mon, 22 Jul 2019 16:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BH8YNOKbSBNG; Mon, 22 Jul 2019 16:21:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3399120048; Mon, 22 Jul 2019 16:21:40 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C4F6C548002; Tue, 23 Jul 2019 01:21:35 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BDF9C440041; Tue, 23 Jul 2019 01:21:35 +0200 (CEST) Date: Tue, 23 Jul 2019 01:21:35 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: Eric Rescorla , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, The IESG , anima@ietf.org, Sheng Jiang Message-ID: <20190722232135.l5amjrneiciu43m6@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190716233939.GC58520@kduck.mit.edu> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:21:45 -0000 --- Context: I hope i am correctly restating, that this reply is as follows: -> Eric reviewed -16, i posted reply into -19, then Erics term as AD finished, then Ben (Kaduk) stepped in for Eric, responded to my -19 fixes for -16, and this email is my reply. Integrated into -20 -> The diff for the changes discussed in this email is: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.1.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt They are also summarized under section (2) of the -20 changelog. -> The total changes -19 to -20 are of course: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt --- Reply: On Tue, Jul 16, 2019 at 06:39:41PM -0500, Benjamin Kaduk wrote: > Not Eric, but playing that role for a bit... Hi Eric, nice to meet you. Inline, removed uncontentuous blocks. > > > S 6.1.2. > > > > See section 4.2.1.6 of [RFC5280] for details on the subjectAltName > > > > field. > > > > > > > > 6.1.2. ACP domain membership check > > > > > > > > The following points constitute the ACP domain membership check of a > > > > > > What is the relationship of these rules to the existing 5280 rules? > > > > Note that there where already i hope good improvements in this text from -16 > > you reviewed to -18. > > My read here is that we could address this by "we use the standard PKIX > [RFC 5280] certificate validation rules with some additional ACP-specific > procedures. In particular: [...]". That is, have a statement about the > relationship of this procedure to the 5280 rules (namely, we add to them), > to make clear that we are not trying to do some similar but subtly > different thing. The ACP certificate check is really more about authentication and authorization, rfc5280 mostly about formatting, not saying what you're supposed to do, but how to format it if you do. The only authentication related stuff i found in rfc5280 that is relevant is the cert-chain-check procedure, that the ACP text is accordingly referring to. So, i tried to solve your ask as follows: I inserted a new subsection at the beginning of "6.1 ACP Domain, Certificate and Network" to talk about the certificate itself (before the ACP domain membership check): | ACP domain certificates are compliant X.509 certificates. | | ACP domain certificates MUST be ECC certificates which SHOULD be signed with an ECDH public key. It MAY be signed with an RSA key. Any secure channel protocols used for the ACP as specified in this document or extensions MUST therefore support authentication (e.g.:signing) starting with these type of certificates. See for more information. | | ... existing text moved here... | The ACP domain membership check requires a minimum amount of elements in a certificate as described in . All elements are compliant. The identity of an ACP node in the ACP is carried via the ACP Domain Information Field (see encoded as an existing rfc822Name field. That part about ECC is the best i can come up right now as a interoperability (at sufficient security) requirements for the certs themselves - independent of specific protocols (IPsec, TLS, DTLS, ...). And of course this needs to go into a cert specific section, not a security protocol specific section. If we are missing more cert parameters for interop, we can add them here. But i didn't find any good RFC yet for more. all the good protocol interop RFCs i found was something like "Cryptographic recommendations regarding certificate validation are out of scope of this document. What is mandatory to implement is provided by the PKIX community" (RFC8247) *sigh*. Then in the ACP domain membership check section i did the following fixes: Refined points 2 and 3 to be more explicit with references (especially pointing out that point 2 has nothing to do with rfc5280): | The peer has proved ownership of the private key associated with the certificate's public key. This check is performed by the security association protocol used, for example , section 2.15. | The peer's certificate passes certificate path validation as defined in , section 6 against one of the Trust Anchors associated with the ACP nodes ACP domain certificate (see below). Finally, i restated the summary in a way that hopefully also makes the relationship to pre-existing standards easier to understand: | In summary: | | Steps 1...4 constitute standard certificate validity verification and private key authentication as defined by and security association protocols (such as IKEv2 when leveraging certificates. These steps do not include verification of any pre-existing form of non-public-key-only based identity elements of a certificate such as a web servers domain name prefix often encoded in certificate common name (this is done in step 5 and 6). | Step 4 Constitutes standard CRL/OCSP checks refined for the case of missing connectivity and limited functionality security association protocols. | Step 5 Checks for the presence of an ACP identity for the peer. Steps 1..6 authorizes to build any secure connection between members of the same ACP domain except for ACP secure channels. | Step 6 is the additional verification of the ACP address. Steps 1...6 authorize a security association be used as an ACP secure channel. | Hope this solves the ask. > > > S 6.1.3.1. > > > > The objective value "SRV.est" indicates that the objective is an > > > > [RFC7030] compliant EST server because "est" is an [RFC6335] > > > > registered service name for [RFC7030]. Future backward compatible > > > > extensions/alternatives to [RFC7030] may be indicated through > > > > objective-value. Future non-backward compatible certificate renewal > > > > options must use a different objective-name. > > > > > > EST runs over HTTPS. What is the certificate that the server presents? > > > > I could add text like: > > > > The EST server MUST present a certificate that > > is passing ACP domain membership check () in its HTTPS > > () connection setup. > > As some background, in general, whenever we use HTTPS (or even just TLS), > the client needs to have some procedure for how to verify that the server > is the entity the client is attempting to talk to. This is almost always > certificate validation, but in addition to ensuring that the signatures > chain up to a trusted root, the client needs to ensure that the entity that > got certified is the (usually named) entity it wants to talk to. So, we > might talk about validating that the cert has an RFC 6125 DNS-ID or SRV-ID > that matches the initial name that the client sent into DNS, if we were > going to use the web PKI. Here, we don't necessarily have or want the web > PKI since we can have ACP domain certificates as well. > > So with my current understanding of the intent (sic) behind the ACP, you do > need to include text with this sort of membership check, and probably also > want a "the client SHOULD require that the server's certificate include a > (as-of-yet, site-specific) X.509 extension to indicate that it is > authorized to function as an EST server". (Actually I thought there was > something very similar that is already defined and was mentioned in BRSKI, > but I'm failing to remember the right search term to find it.) Thanks for the explanations. Yes, we do not want DNS given how ACP would be infra that needs to operate first before the network could bring up DNS (circular dependency). I have now added the following text to 6.1.4. This is before the GRASP objective as this has nothing to do with GRASP: The EST server MUST present a certificate that is passing ACP domain membership check in its TLS connection setup (, rules 1..5, not rule 6 as this is not for an ACP secure channel setup). The EST server certificate MUST also contain the id-kp-cmcRA extended key usage extension and the EST client must check its presence. The additional check against the id-kp-cmcRA extended key usage extension field ensures that clients would not fall prey to an illicit EST server. While such servers should not be able to support client certificate signing requests (as they are not able to elicit a signing response from a CA), such an illicit server would be able to provide faked CA certificates to clients that need to renew their CA certificates when they expire. Note that EST servers supporting multiple ACP domains will need to have for each of these ACP domains a separate certificate and respond on a different transport address (IPv6 address and/or TCP port), but this is easily automated on the EST server as long as the CA does not restrict registrars to request certificates with the id-kp-cmcRA extended usage extension for themselves. I sent this to the BRSKI (EST) authors for review as i have only tried to figure out the real attack vector in the 2nd paragraph of above text, and i am not 100% sure. > Talking things through... ...[MITM attack with the ACP proposed simple "try all accepted crypto algos in parallel] > In the MITM case such as this, the idea would be to just drop all > connection attempts other than the "weakest link" so that Alice and Bob > both think that each other don't support the strong mechanisms. Right. > If the attacker can realtime break the weakest link, then they can inject > themselves into the secure connection; if either Alice or Bob (or both) > were unwilling to support the weakest link, then the attacker could only > block traffic but not MITM the secure connection. Right. > Generally we can prevent > this by requiring Alice and Bob to verify what connection types they > respectively support, preferrably by directly using this information as > input to a key schedule (so it *has* to get verified) but a separate > comparison will still work if actually implemented. Then the only other > check is that the negotiated connection is the strongest that's mutually > supported. Since we're doing Alice's preference, Alice would need to make > the check (and Bob is reliant on Alice to detect such MITM downgrade > attacks). For TLS, it's fairly common to stuff this sort of information > into a TLS Extension and have the appropriate party check what the other > side got, but I don't remember a similar mechanism for IKEv2. (Maybe > transform attributes, but I'm not sure.) Trying to make the check happen > after the secure connection is established doesn't work, because by then > the attacker is already in place with the MITM. I guess in the case the > attacker doesn't have a full break, the post-facto check would still let > you detect the attacker's presence. So, first of all, ACP just uses IPsec, DTLS or with additional docs any other crypto mechanisms feasible. Any long-term evolution of the appropriate crypto options with those protocols would equally be benefitting ACP. Aka: RFC8221/RFC8247 and their future evolutions get into IPsec/IKEv2 implementations and raise over time the crypto to counter attacks. Thats of course very long term. Whats discussed here is really about supporting multiple, mutually incompatible crypto protocols such as IKEv2 and DTLS (MACsec would be my next favourite). I don't think there are any perfect solutions for this case unless you're willing to crearte a network wide mandatory to implement secure channel protocol, which would drastically reduce the flexibility and range of devices that could be supported. Assume low end devices would never want to do IKEv2, and you just choose IKEv2 as network wide MTI. I also proposed multi-stage, aka: start with TLS, use that only to negotiate what to really do, e.g.: across all IKEv2, DTLS, MACsec, etc. option. That was before your time as AD, and was fored out even from an appendix due to being too complex (and also creating just another MTI). > It does seem like we should be able to do at least a little better than > "just trust everybody to disable bad connection types when they are known > to be broken". Well, and thats IMHO not even a good example of what operators really need to happen: consider the update to the security policy is (for the sake of the argument) something like: we need to raise minimum keylength from X to Y. Lets figure out if all nodes support this. Oh darn. These type of nodes can't. Can we replace them ? Oh, expensive. Lets see, the MITM have to be locally originated. Whats the risk for this to happen. Ok, 70% of those nodes are in location where the likelyhood of local attack is farily low, lets start with those other 30% first, shut them down and get them physcially replaced, and work in the meantime on the remaining 70% maybe we can force the vendor to build a better firmware upgrade with more security. Aka: We can come up with easy flooding of updated security policies via GRASP (we've got drafts lying around to do so), but its highly unlikely that you really can make a lot of real-world security progress with very simple network wide policies on these complex judgement calls about security communication channels. But of course ANIMA will be very happy to get proposals what type of agile crypto-agility policies are desirable. We serve to please ;-) > > > S 8.1.5. > > > > interface is physically protected from attacks and that the connected > > > > Software or NMS Hosts are equally trusted as that on other ACP nodes. > > > > ACP edge nodes SHOULD have options to filter GRASP messages in and > > > > out of ACP connect interfaces (permit/deny) and MAY have more fine- > > > > grained filtering (e.g., based on IPv6 address of originator or > > > > objective). > > > > > > Given that this is an important security requirement, it seems like it > > > should be a normative requirement that it be filtered. > > > > This is not a security requirement but an administrative policy filtering > > requirement. You assume the servers you allow to connect to an ACP connect > > network to be trusted. They may just not provide flexible filtering of > > the services they offer so the network device can add that through above > > mentioned policy filtering of the GRASP announcements. > > "this is a trusted network" does tend to get skeptical responses from the > IETF security community, it is true. Ok, but now your point sems to be different than your initial ask for making filtering mandatory. First of all, i have changed the text outlining the security expectations, pls. let me know if the following is more acceptable to you: | Given how the ACP is the security and transport substrate for GRASP, the requirements | for devices connected via ACP connect is that those are equivalently (if not better) | secured against attacks and run only software that is equally (if not better) | protected, known (or trusted) not to be malicious and accordingly designed to isolate | access to the ACP against non-equally protected/trusted external equipment. | | The difference in security is that cryptographic security of the | ACP secure channel is replaced by required physical security of the network connection | between an ACP edge node and the NMS or other host reachable via the ACP connect | interface. Node integrity too is expected to be easier because the ACP connect | node, the ACP connect link and the nodes connecting to it must be in a contiguous | secure location, hence assuming there can be no physical attack against the devices. If the way this describes the security is ok. with you, i might still want to move it to a different place in the doc as i am not sure this GRASP specific section is really the best place for this more generic text. But no use moving this text unless we agree upon how to appropriately word the security expectations of ACP connect. Especially given the big divide between a lot of IETF security people only considering cryptographic security real security (where the ACP channel fits) vs. typical intra-NOC/DC setups, where solution often only work because of a lot of methods and layers of physical security (which is where ACP connect is meant to live, if its not purely between VMs/Containers in a single device). Secondly, i simply erased the text about ACP edge nodes filtering of GRASP because i don't want it to be perceived as a security requirement (like you did) when its just a suggestion for a policy function from deployment experience with pre-standard solution where we used mDNS and the announcements from NOC servers where often contradicting, wrong or missing, and we would had to have a policy function to "massage" those service announcement. Maybe service announcement broker would be a better way to think about it. Still something i think is needed overall, but not foundational enough to justify a presence here in this document. > -Ben Thanks a lot, Eric (*grin*) Cheers Toerless From nobody Mon Jul 22 16:23:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4C2120094; Mon, 22 Jul 2019 16:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nHgYvSU1RSFE; Mon, 22 Jul 2019 16:22:51 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C6D120048; Mon, 22 Jul 2019 16:22:50 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E4B8E548002; Tue, 23 Jul 2019 01:22:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DE086440041; Tue, 23 Jul 2019 01:22:43 +0200 (CEST) Date: Tue, 23 Jul 2019 01:22:43 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20190722232243.xsuvmozrnl2dcpyx@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156331768227.15267.2488890611024053018.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:22:58 -0000 --- Context: I hope i am correctly restating, that this reply is as follows: -> After finishing second round of replies for -16, Ben Kaduk provided a reply that is now also his new DISCUS position on datsatracker. this is my reply to that DISCUS. -> The diff for the changes discussed in this email is: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt They are also summarized under section (3) of the -20 changelog. -> The total changes -19 to -20 are of course: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt --- Reply: Thanks a lot Ben. I hope this leaves open two points: -> ASN encoding of domain-information. See compromise proposal in answer to DISCUSS. -> Some hopefully minimal parameters for crypto. - mentioned in the according discuss/nits. - I'll also draft another separate email thread to quickly close on this and try to see if we can suck in others from some of he reference docs into the solution - or other IPsec experts you would suggest. Rest inline. On Tue, Jul 16, 2019 at 03:54:42PM -0700, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-19: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [trimming to just the topics still under discussion; no change to the > text of the remaining items even though some changes have been made > to the document] > > I think there needs to be some justification of why rfc822Name is chosen > over a more conventional structure in the otherName portion of the > subjectAltName, which is explicitly designed to be extensible. Let me but the compromise proposal and conditions on top: Compromise proposal (not integrated into current text yet): The document defines a new otherName like ACPdomainIdentity, type IA5String I can figure out how to write the the necessary formal text for this, stealing from e.g.: rfc8398 or the like (asking for IANA registration etc..) i will whine for help (from you) when i fail with that text formalisms/ASN1. stuff. The encoding of the string is the existing domain-information The length limitation of 64 for the local part is lifted (yeah). The rest of the text (justification for formatting etc.) is appropriately fixed up. I will remove all the text suggesting this could be an actual rfc822 address and just escribe it in terms of below reasoning (nice format to express domain based identities "local+policies@domain" or the like. Condition: Sufficient support in WG (tomorrow meeting) wrt. the following key aspects: -> Belief that even the most stupid existing libraries to deparse certificates can give access to this information without rev'ing such libraries (we assume this is true for rfc822Name). -> Ability of a good amount of existing diagnostics tools to actually display the string content as a string, even when it obviously doesn't know what type the otherName is. This is based on my hope that i correctly understand BER/DER to be self identifying, so deparser would know the element is string, but thats's what i am not sure about. Reasons: - We need both a human readable and in-cmputer representation of the information. I really don't see enough reason to have two different ones, and i really don't want to write to structure defintions. So i think the existing ABNF string is nice for both purposes. This info will go into all type of backend systems, inventory tracking etc.. deparsing specifically formatted strings is quite common there. - The domain-information is really the non-cryptographic part of the ACP device identity. and the local@domain part is an established way to represent this, so its hopefully "nice" too - e.g.: i woldn't know a more appropriate format. > In a few places, the MTI cryptographic mechanisms are under-specified, > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > to note these locations in my section-by-section comments. Right. a) I couldn't find good references for certificate requirements. The IPsec/IKEv2 reference STANDARDS RFCs lamely said something like "problem for the PKIX community". (seems like a gapipng big interop hope for those protocols if it doesn't exist). b) I am confused about TLS parameters needed beside what i wrote in latest update. See nit discuss below. > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > root, but if I understand correctly the RPL root is automatically > determined within the ACP, and thus the operator does not a priori know > which node will become the RPL root. Am I misunderstanding, or is this > effectively placing this requirement on all ACP nodes? Fixed by adding an option to not ask for this diagnostics to lowest-end nodes least in line to become root. When one of those nodes becomes root, the network is already in a worst degraded state, so this advanced diagnostics is then likely the least of problems. Details in reply to original -16 review answer you sent. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for adding the implementation experience note to the shepherd > writeup; it is helpful to understand the maturity level of the document. > > The comments here are probably best understood in the context of my > previous ballot position, specifically with respect to certain topics > being "speculative" or a matter for "future work". > > One somewhat general comment that occurred to me on the reread is that > by encoding the ACP address into a node's LDevID, we are on the face of > things locking it into a given addressing model, though in practice it > should be fairly straightforward to issue a new certificate through > regular update/renewal mechanisms. I forget if we have discussion of > this non-issue already. Readdressing is possible, but the address is really the non-security part of the identity of an ACP node (security part is key-pair), so all the ACP text talks about trying to maintain it whenever possible (discussed in the text for example in the face of change of registrars, so the originally assigning registrar is gone). There is really nothing breaking in the ACP when ACP nodes change their addresses, but typically the short-term adoptions of ACP into non-fully autonomic environments would love to see persistent addresses, because thats what they do today: Operators have used IP addresses as ideally never-changing network services identifiers of nodes for decades (loopback addresses). Thats just what we do with ACP, and the assignment via certificate is an elegant way to solve the current manual problem of network wide unique assignment, it just gets a bit complicated under the hood in above mentioned cases (registrar change during cert renewal). The use of well-defined address plans standardized in the ACP document is also something that effectively just automates operational practices and keeps deployment specific options at a minimum. > Section 1 > > Combining ACP with Bootstrapping Remote Secure Key Infrastructures > (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the > "Autonomic Network Infrastructure" as defined in > [I-D.ietf-anima-reference-model], which provides autonomic > connectivity (from ACP) with fully secure zero-touch (automated) > bootstrap from BRSKI. The ANI itself does not constitute an > > nit: It's unclear that there's universal agreement about what "fully > secure" might mean, so I'd suggest just using "secure". Done. > Section 2 > > ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate > (LDevID) carrying the domain information field which is used by > > nit: I think the reference is for "certificate", not "provisioned". > > ACP secure channel: A cryptographically authenticated and encrypted > data connection established between (normally) adjacent ACP nodes > to carry traffic of the ACP VRF secure and isolated from Data- > Plane traffic in-band over the same link/path as the Data-Plane. > > nit: I'm not sure if "secure" or "securely" is better (but what does > "secure from" mean?) securely sounds find. fixed. I think its read ... "secure(ly)" and "isolated from". > > Enrollment: The process where a node presents identification (for > example through keying material such as the private key of an > IDevID) to a network and acquires a network specific identity and > trust anchor such as an LDevID. > > nit: the LDevID is the identity; it's not a trust anchor. Fixed to: network specific identity such as an LDevID and trust anchors such as Certificate Authority (CA) certificate. > Section 5 > > 3. For each node in the candidate peer list, it authenticates that > node (according to Section 6.1.2) and negotiates a mutually > acceptable channel type. > > 4. For each node in the candidate peer list, it then establishes a > secure tunnel of the negotiated type. The resulting tunnels are > then placed into the previously set up VRF. This creates an > overlay network with hop-by-hop tunnels. > > nit: the "channel type" of (3) is the "negotiated type" of the "secure > tunnel" in (4), right? It might be nice to use the same word in > both items, to help tie the language together. Changed to "negotiated channel type in 4". > Section 6 > > nit: "must have it's ACP domain certificate" gained an apostrophe in "it's" > but the original "its" was correct. fixed. > Section 6.1 > > members. The LDevID is used to cryptographically authenticate the > membership of its owner node in the ACP domain to other ACP domain > members, the TA is used to authenticate the ACP domain membership of > other nodes (see Section 6.1.2). > > nit: comma splice fixed (two sentences). > The ACP does not mandate specific mechanisms by which this keying > material is provisioned into the ACP node, it only requires the > Domain information field as specified in Section 6.1.1 in its domain > certificate as well as those of candidate ACP peers. See > > nit: comma splice fixed (two sentences). > The ACP domain certificate SHOULD be used for any authentication > between nodes with ACP domain certificates (ACP nodes and NOC nodes) > where the required condition is ACP domain membership, such as ACP > > nit(?) I'd suggest s/required condition/required authorization > condition/ fixed. > Section 6.1.1 > > The ABNF in Figure 2 seems to have multiple what I'll call for lack of a > better term "terminal constructions" (i.e., routing-subdomain and > domain-information) that are not used in other rules. Some text on > which one is used in the rfc822Name and which is just informational for > other purposes is probably in order. Added below figure: domain-information is the encoded information that is put into the ACP domain certificates subjectAltName / rfc822Name field. routing-subdomain is a string that can be constructed from the domain-information, and it is used in the hash-creation of the ULA (see below). The requirements and sementics of the parts of this information are explained in the following paragraphs: I think there are no more terminal name than those two. > o The maximum size of "domain-information" is 254 characters and the > maximum size of node-info is 64 characters according to [RFC5280] > that is referring to [RFC2821] (superseded by [RFC5321]). > > nit: I don't think we refer to node-info anywhere. s/node-info/local-part/ > On the topic of rfc822Name vs. otherName, I note that there's no > requirement to use ASN.1 for the internal structure of the value; it's > perfectly acceptable to make it an OCTET STRING and shove a > more-friendly data structure in there. (It's a little bit weird in > terms of mental models, but funny looks aside, it's pretty common.) If > the other structure is fixed-length, there is not any actual ASN.1 > knowledge required by the recipient; they just check that the length is > right and the data starts with the correct fixed prefix (corresponding > to the OID and ASN.1 length encoding), before processing the encoded > data in whatever manner is appropriate. Since we want to put domain > names in, fixed-length is probably out of the figure, but even if we're > limited to what openssl provides, getting an ASN1_OCTET_STRING and > extracting its contents to a pointer+length is pretty well established; > we don't need to make people learn about ASN1_SEQUENCE() at all. So you > could have the fundamental structure of the otherName be something like: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------------------------------------------------------+ > | Flags |M|A| > +---------------------------------------------------------------+ > | | > + + > | | > + [acp-address] + > | | > + + > | | > +---------------------------------------------------------------+ > | rsub-len | rsub... | > +------------------------------+ + > ~ ~ > +---------------------------------------------------------------+ > | acp-domain-len | acp-domain... | > +------------------------------+ + > ~ ~ > +---------------------------------------------------------------+ > | [TLV extensions] | > +---------------------------------------------------------------+ > > where M means that the holder of the cert is allowed to establish an ACP > secure channel (what the '0' acp-address does in the present > formulation) and A means that the acp-address field is present > > and just pack that into an OCTET STRING. > > Is the rfcSELF@acp.example.com email address for human use really > providing much value? This is pretty clearly breaking an abstraction > barrier, from my point of view. See above at the DISCUSS for my list of reasons to go with the rfc822name encoding. Compared to your (more efficient) encoding, its specifically about diagnostics and the ability for any existing certificarte tool to correctly display a string for an existing field (rfc822name). What would a randomn existing tool show a human for your field ? could i easily copy & paste it, could i easily have a script put it into a list, copy into excel spreadsheet (annoyingly enough we still live in a world where we need to deal with humans and their preferences. We're trying to minize what humans need to manage in ANIMA/ACP, but this is exactly the pieces they will need to deal with whenever they troubleshoot). We wouldn't only have to redo the whole encoding into the certificate as you proposed, but also come up with recommended standard representations for humans to make it easy to operate across all type of tool chains where humans are involved. Which could be the rfc822 representation because its kinda nicely human logical ("node+tags@domain"...). > It also makes acp-domain-name a valid e-mail target across all > routing-subdomains. > > nit: rfcSELF@acp-domain-name actually "domain-information", fixed. > o It should be possible to share the LDevID with other uses beside > the ACP. Therefore, the information element required for the ACP > should be encoded so that it minimizes the possibility of creating > incompatibilities with such other uses. > > otherName with an ACP-specific OID has zero possibility of collisions > with other uses; reusing rfc822Name has nonzero possibility of > collision. (Note that having multiple otherNames is allowed.) Q1: Who allocates the OID ? Q2: Could we put the currently domain-information into the otherName as a string ? Q3: Would existing tools that deparse certificates human readable display OtherNames that are string type (with e.g.: BER) ? > o The information for the ACP should not cause incompatibilities > with any pre-existing ASN.1 software. This eliminates the > introduction of a novel information element because that could > require extensions to such pre-existing ASN.1 parsers. > > Even getting to the rfc822Name requires some level of ASN.1 parsing, so > it's unclear how strong this argument really is. >From what we discussed in the WG, all ASN.1 parsers people knew would already be able to parse those defined fields, especially rfc822Name > > o The element required for the ACP should not be misinterpreted by > any other uses of the LDevID. If the element used for the ACP is > interpreted by other uses, the impact should be benign. > > [OIDs are by construction unique] See Q1. > o At minimum, both the AN domain name and the non-domain name > derived part of the ACP address need to be encoded in one or more > appropriate fields of the certificate, so there are not many > alternatives with pre-existing fields where the only possible > conflicts would likely be beneficial. > > It's even possible to define multiple OIDs for otherName use, one for > acp-domain-name, one for rsub, etc.. But that feels kind of like > overkill to me. See above. I am a lot more partial to keep a easily human readable string representation of the information than using rfc822Name. And i do not really want to bother about two representations (human vs. machine) in this case. Not using rfc822Name would also give the ability to define a longer limit for local-part which is my biggest worry when we're talking future extensions. > Section 6.1.2 > > 3: The peer's certificate passes certificate path validation as > defined in [RFC5280] against one of the Trust Anchors associated > with the ACP nodes ACP domain certificate (see Section 6.1.3 > below). > > nit: "node's" possessive Fixed. > 4: If the node certificate indicates a Certificate Revocation List > (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or > Online Certificate Status Protocol (OCSP) responder ([RFC5280], > section 4.2.2.1), then the peer's certificate must be valid > according to those criteria: An OCSP check for the peer's > certificate across the ACP must succeed or the peer certificate > must not be listed in the CRL retrieved from the CDP. [...] > > side note: we could (but don't have to) note that OCSP stapling is a > way to get an OCSP response to check. Right. thats why i fixed the text already via feedback to i think your first round by adding that this only applies when the security association protocol is incapable to carry the CDP/OCSP information itself. > 5: The peer's certificate has a syntactically valid ACP domain > information field (encoded as subjectAltName / rfc822Name) and the > acp-domain-name in that peer's domain information field is the > same as in this ACP node's certificate (lowercase normalized). > > (Writing this as "has an otherName subjectAltName using the ACP OID" > seems more concise to me, but I'll try to stop beating that horse.) ;-) Let me understand your answers to Q1...Q3 and also tell me what you think about keeping the string ("looks like an email identity") enoding but using your suggested field. > When an ACP node learns later via OCSP/CRL that an ACP peers > certificate for which rule 4 had to be skipped during ACP secure > channel establishment is invalid, then the ACP secure channel to that > peer SHOULD be closed even if this peer is the only connectivity to > access CRL/OCSP. The ACP secure channel connection MUST be retried > periodically to support the case that the neighbor aquires a new, > valid certificate. > > nit: we could probably tighten up the writing here about "MUST be > retried periodically" in terms of needing to reestablish the TLS > connection provisionally and repeat the initial connection steps, though > on second read the current text seems better than I thought on first read. I will not take action against this comment as i am not clear what the suggestion exactly is. Do you want me to try to cut the first sentence into multiple smaller ones to make sound less like a german hold hostage by the english language (or vice versa). > Only when checking a candidate peer's certificate for the purpose of > establishing an ACP secure channel, one additional check is > performed: > > nit: I'd suggest s/Only when/When/ Done. > Formally, the ACP domain membership check includes both the > authentication of the peers certificate (steps 1...4) and a check > authorizing this node and the peer to establish an ACP connection > and/or any other secure connection across ACP or data-plane end to > end. Step 5 authorizes to build any non-ACP secure connection > between members of the same ACP domain, step 5 and 6 are required to > build an ACP secure channel. For brevity, the remainder of this > document refers to this process only as authentication instead of as > authentication and authorization. > > I'd prefer to see a penultimate sentence along the lines of "Other > authorization models are possible by local policy, but for this > specification (and to some extent, autonomic systems in general), domain > membership is deemed sufficient authorization for all operations." "_local_ policy" is in general a big no-no for us except where we can't avoid it, so i better don't say "local" this without good reason. I also don't find this section specifically talking about ACP Domain membership check the right place to say this. I did ad the following paragraph to the new section 6.1.1 about ACP domain certificates: Note that is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with future requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. For example, see . Aka: that example in the appendix already is explaining our recognition that for higher layers at least roles seem to be clearly needed to create better security. Indeed the flag in the certificate for an EST server is really just a speific example of such a role. Except that it seems to be called "extended certificate usage" instead of role ;-). > Section 6.1.3 > > A certificate path is a chain of certificates starting at a self- > signed certificate of a so called root-CA or Trust Anchor, followed > > nit(?): I'm used to seeing chain construction start at the > leaf/end-entity and chain up to the root, but to some extent this is an > editorial question. In routing and biology, trees start at the root, so pls. excuse my ignorance ;-) fixed to: A certificate path is a chain of certificates starting at the ACP certificate (leaf/end-entity) followed by zero or more intermediate Trust Point or sub-CA certificates and ending with a self-signed certificate of a so called root-CA or Trust Anchor. > A single owner can operate multiple independent ACP domains from the > same set of private trust anchors (CAs) when the ACP Registrars are > trusted not to permit certificates with incorrect ACP information > fields to be signed. Such as ACP information with a wrong acp-domain > field. [...] > > nit: This last sentence is a sentence fragment (I suggest joining it to > the previous one with a comma). Done. > Section 6.1.4 > > with its ACP domain certificate. When BRSKI (see > [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of > the BRSKI registrar from the BRSKI TLS connection SHOULD be > remembered and used for the next renewal via EST if that registrar > also announces itself as an EST server via GRASP (see next section) > on its ACP address. > > IIUC, the BRSKI spec currently advertises BRSKI registrars with the > EST-TLS objective, and I don't really understand how this interacts with > SRV.est or whether this text should change. The equivalent to the SRV.est announcement is actually in BRSKI the AN_join_registrar announcement. A registrar that does both BRSKI (initial enrollment) and renewal (EST propoer) would send both announcements. I think this text is fine. > Section 6.1.4.1 > > The objective name "SRV.est" indicates that the objective is an > [RFC7030] compliant EST server because "est" is an [RFC6335] > registered service name for [RFC7030]. Objective-value MUST be > ignored if present. Backward compatible extensions to [RFC7030] MAY > be indicated through objective-value. Non [RFC7030] compatible > certificate renewal options MUST use a different objective-name. > > I'd consider adding some text about ignoring unrecognized > objective-values, to attempt to preserve the usability of this extension > point. Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored. > Section 6.1.4.3 > > The ACP node SHOULD support Certificate Revocation Lists (CRL) via > HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) > > My understanding is that HTTP-not-s is commonly used for CRL > distribution since the CRL content itself is signed, and there would be > a risk of a circular dependency in validating the server's TLS > certificate to get to the CRL information. Fixed. > HTTPs connections. The connecting ACP node SHOULD verify that the > CDP certificate used during the HTTPs connection has the same ACP > address as indicated in the CDP URL of the nodes ACP domain > certificate if the CDP URL uses an IPv6 address. > > nit: "node's" possessive. fixed. > Section 6.1.4.5 > > enrollment. Using the ACP node's domain certificate allows the BRSKI > registrar to learn that nodes ACP domain information field, so that > > nit: "node's" possessive. fixed > with its old ACP certificate. The re-enrolling candidate ACP node > SHOULD only request a voucher from the BRSKI registrar when this > authentication fails during TLS connection setup. > > I might suggest "SHOULD only fall back to requesting a voucher". fixed. > Section 6.1.4.6 > > An ACP domain certificate is called failing in this document, if/when > the ACP node can determine that it was revoked (or explicitly not > renewed), or in the absence of such explicit local diagnostics, when > the ACP node fails to connect to other ACP nodes in the same ACP > domain using its ACP certificate. For connection failures to > > nit: maybe "the ACP node to which the certificate was issued", since > when I first read this I was expecting it to be about telling that some > other node's certificate is failing, not a node's own certificate. fixed. > Section 6.5 > > At this time in the lifecycle of ACP nodes, it is unclear whether it > is feasible to even decide on a single MTI (mandatory to implement) > security association protocol across all ACP nodes. > (This is a future-looking statement that implies uncertainty in the > current spec.) Yikes. How did this sentence survive so long. With all the other places pounding on the key thing being to not mandate a single network wide MTI because there is sufficient insight that it would be way too limiting. removed. Thanks a lot. > [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, > therefore Node 1 considers itself Bob and Node 2 Alice > on connection C1, but they also identify that C2 is to the > > I think this first "Node 2" should be "Node 1"? Fixed. > interface" that they both connect to. An autonomic node must not > assume that neighbors with the same L2 or link-local IPv6 addresses > on different L2 interfaces are the same node. This can only be > determined after examining the certificate after a successful > security association attempt. > > This could potentially be a "MUST NOT". fixed. > Section 6.7.1.1 > > To run ACP via IPsec natively, no further IANA assignments/ > definitions are required. An ACP node that is supporting native > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and > peer link-local IPv6 addresses used for encapsulation. It MUST then > support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 > hash and MUST NOT permit weaker crypto options. Key establishment > MUST support ECDHE with P-256. > > I don't think "SHA256 hash" is quite specific enough (and we probably > want GMAC for integrity anyway). In the answer to your i already changed this text to ENCR_AES_GCM_16. The way i understand it (pls. help me if i am wrong), it comes with its own integrity protection mechanism. Pls. check new text in 6.7.1.1 > Section 6.7.1.2 > > To run ACP via GRE/IPsec, no further IANA assignments/definitions are > required. An ACP node that is supporting ACP via GRE/IPsec MUST then > support IPsec security setup via IKEv2, IPsec transport mode, local > and peer link-local IPv6 addresses used for encapsulation, ESP with > AES256 encryption and SHA256 hash. > > Why is IPsec/GRE using AES256/SHA256 when IPsec native is using > AES256-GCM? Error in duplication. New text from your and erics review removes all duplication and has GRE just refer to the native requirements and only explain changes. > Section 6.7.2 > > We define the use of ACP via DTLS in the assumption that it is likely > the first transport encryption code basis supported in some classes > of constrained devices. > > nit: I don't think "basis" is quite the right word, here; maybe "base" > (or collapsed back to "codebase" as one word) or omit it entirely. deleted term. > Section 6.7.3 > > support DTLS. An ACP node connecting an area of constrained ACP > nodes with an area of baseline ACP nodes MUST therefore support IPsec > and DTLS and supports therefore the baseline and constrained profile. > > nit: this could probably work just fine as a non-normative "must", since > it's just describing facts. fixed. > Section 6.8.2 > > nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces" > in the second box from the top. > fixed > ............................................................... > . | | | ^^^ Users of ACP (GRASP/ASA) . > . | | | ACP interfaces/addressing . > . | | | . > . | | | A > . | ACP-Loopback Interf.| <- ACP Loopback interface C > . | ACP-address | - address (global ULA) P > . subnet1 | subnet2 <- ACP virtual interfaces . > . link-local | link-local - link-local addresses . > ............................................................... > > I'm still a bit confused by this box in the figure -- is the "Users of > ACP" label supposed to apply to the previous box(es) or the current one? > If the former, it's confusing to see the "ACP security and transport > substrate for GRASP" being described as a "user of ACP". Changed to "Users of ACP interfaces". Alas i have no more lines without breaking the picture onto multiple pages in RFC TXT so i can not well try to carve out better space to show where ASA sit (difficult as they would use both ACP interfaces as well as some GRASP API. > GRASP unicast messages inside the ACP always use the ACP address. > Link-local addresses from the ACP VRF must not be used inside > objectives. GRASP unicast messages inside the ACP are transported > via TLS 1.2 ([RFC5246]) connections with AES256 encryption and > SHA256. Mutual authentication uses the ACP domain membership check > defined in (Section 6.1.2). > > Just "AES256 encryption and SHA256" describes quite a few TLS > ciphersuites > (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4); > I'd suggest limiting to a specific handful like > "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" (the "Recommended" column in > the registry will be helpful at picking things). > It's probably also useful to specify a RSA/ECDSA key size (and elliptic > curve for ECDSA) and the nature of the ECDHE or DHE. Can you please suggest recommended text here ? I spent a lot of reading up on the whole IPsec/channel level especially also because you indicated we would need other folks to help on IPsec, but i figure you would be a good person to ask for TLS. Given how this is all new code, i see no reason to have mor than one MTI, its also easy to override at application level (this would ahppen for application scoped GRASP TLS connections). How about mandating LS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 I have no idea how ECDHE are intermixed with RSA here, and what key sizes we talk about - i hope the one from the cert, but the cert would only hae one type of public key, ECDHE or RSA, right ? > Section 6.8.2.1 > > If GRASP peer connections would just use TCP, compromised ACP members > could simply eavesdrop passively on GRASP peer connections for whom > they are on-path ("Man In The Middle" - MITM). Or intercept and > > nit: I'd suggest "were to use just TCP". fixed. > modify them. With TLS, it is not possible to completely eliminate > > nit: sentence fragment merged with prior sentence. > > Section 6.10 > > Links inside the ACP only use link-local IPv6 addressing, such that > each nodes ACP only requires one routable virtual address. > > nit: "node's" possessive. fixed. > Section 6.10.2 > > o Establishing connectivity between different ACP (different acp- > domain-name) is outside the scope of this specification. If it is > being done through future extensions, then the rsub of all > routing-subdomains across those autonomic networks need to be > selected so their hashes do not collide. For example a large > > nit: the grammar could be more clear that it's hash(routing-subdomain) > that must be collision-free, rather than hash(rsub) Fixed to .. so the resulting routing-subdomain hashes.. > Section 6.10.7.2 > > information - ACP domain-name, ACP-address, and so on. If the ACP > registrar uses BRSKI, it signals the ACP domain information field to > the Pledge via the EST /csraddrs command (see > [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR > Attributes"). > > I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030 > (and the section number is probably stale as well, as the RFC Editor > note attests). Oh, but /csrattrs is very close, so this is likely just > a typo. fixed to csrattr, section now 5.9.2 in brski-22 > Section 6.10.7.3 > > scheme. The first address of the prefix is the ACP address, all > other addresses in the prefix are for other uses by the ACP node as > described in the zone and Vlong addressing sub scheme sections. The > > nit: comma splice fixed. > policy. For example, in BRSKI, the ACP registrar is aware of the > IDevID of the candidate ACP node, which contains a serialNnumber that > is typically indicating the nodes vendor and device type and can be > > nits: "serialNumber", "node's vendor" possessive fixed > > ACP registrars SHOULD default to allocate ACP zone sub-address scheme > addresses with Subnet-ID 0. Allocation and use of zone sub-addresses > with Subnet-ID != 0 is outside the scope of this specification > > nit: it's only referred to as "Subnet-ID" in the manual addressing > sub-scheme; for the zone addressing sub-scheme it's "Zone-ID". > *yikes*. Good catch. There was one more further down of this mistake. fixed. > Section 6.11.1.1 > > Additionally, failed ACP tunnels can be quickly discovered the secure > channel protocol mechanisms such as IKEv2 Dead Peer Detection. This > > nit: missing word, maybe "through the secure channel protocol" fixed. > Section 6.11.1.9 > > [RFC6550] security not used, substituted by ACP security. > > Because the ACP links already include provisions for confidentiality > and integrity protection, their usage at the RPL layer would be > redundant, and so RPL security is not used. > > The ACP links provide only hop-by-hop security, but it looks like at > least some of the RFC6550 mechanisms provide more global source > authentication. (I'm not suggesting we change the protocol to use RPL > security, just noting that this text is not quite right about being > entirely redundant.) I really have no idea. I had these profile template points be filled out by Pascal Thubert, so i would assume it is correct. I forwarded the nit to him, let's see what he says. > Section 6.11.1.14 > > I still think it's worth calling out that the RPL root is not > necessarily preconfigured and this "SHOULD" requirement could > potentially apply to any node, but this is only Comment-level and you > should feel free to ignore it. Check the paragraph i inserted into the section for your first review email talking about how this does not apply to nodes supporting only "default" administrative preference. Hope this is a good trick to aleviate the need for forwarding plane enhancemeents on that wouldn't never become root in a network operating in a state where this diagnostic function would be useful. > Section 6.12.5 > > Care must also be taken when creating multi-access ACP virtual > interfaces across ACP secure channels between ACP nodes in different > domains or routing subdomains. The policies to be negotiated may be > described as peer-to-peer policies in which case it is easier to > create ACP point-to-point virtual interfaces for these secure > channels. > > nit: the text is unclear about what sort of policies are being > negotiated. Changed sentence to: If for example future inter-domain ACP policies are defined as "peer-to-peer" policies, it is easier to create ACP point-to-point virtual interfaces for these inter-domain secure channels. > Section 8.1.1 > > When an ACP Edge node receives a packet from an ACP connect > interface, it MUST only forward it intot he ACP if it has an IPv6 > > nit: "into the" fixed. > Section 9.1 > > when using OCSP/CRL. The same benefit can be achieved when using > CRL/OCSP, periodically refreshing the revocation information and > also tearing down ACP secure channels when the peers (long-lived) > certificate is revoked. There is no requirement against ACP > > nit: "peer's" possessive fixed. > partition is left with one or more of such ACP registrars, it can > continue to enroll new candidate ACP nodes as long as the ACP > registrars sub-CA certificate does not expire. Because the ACP > > nit: "registrar's sub-CA" possessive fixed. > Section 9.2.2 > > not the Data-Plane. Especially for those management plane functions > that have no good protection by themselves because they do not have > secure end-to-end transport and to whom ACP does not only provides > automatic reliable connectivity but also protection against attacks. > > nit: s/does not only/not only/ fixed > Section 9.3 > > An ACP is self-forming, self-managing and self-protecting, therefore > has minimal dependencies on the administrator of the network. > Specifically, since it is (intended to be) independent of > configuration, there is no scope for configuration errors on the ACP > itself. The administrator may have the option to enable or disable > > nit: Given that Section 8.2.1 talks about configuring ACP neighbors and > 8.2.2 about configuring tunneled neighbors, I'd suggest to s/no > scope/only limited scope/, fixed. > and perhaps similar tweaks in the following paragraphs. fixed to. While configuration (except for and ) is not possible > Section 10.1 > > o Check the validity of the domain certificate: > > * Does the certificate authenticate against the trust anchor? > > nit: s/authenticate/validate/ fixed. > - The neighbors certificate does not have the required > trust anchor. Provide diagnostics which trust anchor it > has (can identify whom the device belongs to). > > - The neighbors certificate does not have the same domain > (or no domain at all). Diagnose domain-name and > potentially other cert info. > > - The neighbors certificate has been revoked or could not > be authenticated by OCSP. > > - The neighbors certificate has expired - or is not yet > valid. > > nit: s/neighbors/neighbor's/ (every time) fixed > Section 10.2.2 > > For BRSKI or other mechanisms using vouchers: Parameters to > determine how to retrieve vouchers for specific type of secure > bootstrap candidate ACP nodes (such as MASA URLs), unless this > information is automatically learned such as from the LDevID of > candidate ACP nodes (as defined in BRSKI). > > I thought the LDevID was essentially synonymous with "ACP domain > certificate" in this document, so I can't understand what this means > (unless IDevID was intended). Yes, this and i think one or two more typos LDevID -> IDevID where fixed already for your first review email. > Section 10.2.3 > > Even when such a malicious ACP registrar is detected, resolving the > problem may be difficult because it would require identifying all the > wrong ACP domain certificates assigned via the ACP registrar after it > was compromised. And without additional centralized tracking of > assigned certificates there is no way to do this. > > side note: RFC 6962-style certificate transparency is a somewhat > decentralized way to do such tracking, though I do not think the > engineering tradeoffs favor trying to use it for this situation. Interesting RFC. i pondered adding a reference to it, because some of the actual logging data structures seems quite useful, but the openness model would very likely scare operators off ("ACP makes me public how many and what nodes my network has ??? go away"). > Section 10.2.5 > > Which candidate ACP node is permitted or not permitted into an ACP > domain. This may not be a decision to be taken upfront, so that a > per-serialNumber policy can be loaded into ever ACP registrar. > > nit: "every" fixed. > Section 10.3.x > > I still think the document quality here is not as mature as the majority > of the document, though concede there is value in covering these topics > to some extent in the initial work. Copied from reply to your first mail: Not sure how i could bake it better, but it would probably not be worth it in this document, given how this is mostly food for thought not impacting interoperability and standardization would only come through implementation and deployment experimentation followed by some Yang model. Other reviewers (Joel if i remember correctly) where grumbling, but couldn't provide any better suggestions of how to make operator level interface shutdowns more resilient against unintential network disconnect. Hence i argued strongly to keep this section in there as important food for thought, especially because its been the #1 ask against ACP to figure out by operators i talked to. > Section 10.3.5 > > interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will > operate interface where "ACP/ANI enable" is set. Setting of > > nit: "operate on interfaces where" fixed > Section 10.3.5.1 > > Automatically setting "ANI enable" on brownfield nodes where the > operator is unaware of it could also be a critical security issue > depending on the vouchers used by BRKSI on these nodes. An attacker > could claim to be the owner of these devices and create an ACP that > the attacker has access/control over. In networks where the operator > explicitly wants to enable the ANI this could not happen, because he > would create a BRSKI registrar that would discover attack attempts. > Nodes requiring "ownership vouchers" would not be subject to that > attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more > details. Note that a global "ACP enable" alone is not subject to > these type of attacks, because it always depends on some other > mechanism first to provision domain certificates into the device. > > It's probably worth double-checking that all of these details are still > synchronized with RFC 8366 and the current state of BRSKI. Yepp. Nothing changed as this is very fundamental, but i still rewrote the paragraph somewhat to better express the main concern, which is that an operator with no clue what BRSKI/MASA is even though his devices support it would not attempt to get an account at the MASA and that opens the door to attackers to easier do some form of identity theft "Frank, we got a letter from our router-vendor with techno-mumbo-jumbo-masa-account", "oh, no idea, we're not using that stuff. throw it in the trash bin". And then someone who did forge the request to get the account for the company goes through that company's trash. > Section 10.3.6 > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > reliable operations of the ACP if it can be executed by mistake or > unauthorized. This behavior could be influenced through some > additional property in the certificate (e.g., in the domain > information extension field) subject to future work: In an ANI > > [I don't know if it was intentional or an omission to leave this "future > work" note in place when most others were removed.] I only got rid of all "future" in the normative part, which didn't only consist of removing the word, but moving text out of the normative section referring to this - and this is where such text ended up being (non-normative). Consider this 10.3.x stuff to be staging for hopefully something we would put into YANG in followup work (and as in this case extensions to the cert). (unless we define operator interfaces via YANG, we can't standardize them anyhow). > Section 10.4 > > There is no desirable configuration for the ACP. Instead, all > parameters that need to be configured in support of the ACP are > limitations of the solution, but they are only needed in cases where > not all components are made autonomic. Whereever this is necessary, > it will rely on pre-existing mechanisms for configuration such as CLI > > "will rely on" can also be seen as an indicator for future work. In this case i was just thinking about the future as implementations of this spec, not future features. So i reworded to "it relies on". > > o When the ACP needs to be extended across interfacess other than > L2, the ACP as defined in this document can not autodiscover > candidate neighbors automatically. Remove neighbors need to be > configured, see Section 8.2. > > nit: s/Remove/Remote/ fixed. > Once the ACP is operating, any further configuration for the data- > lane can be configured more reliably across the ACP itself because > > nit: data-plane fixed before. > Section 11 > > o Every ACP registrar is criticial infrastructure that needs to be > hardened against attacks similar to a CA. A malicious registrar > > nit: as written, this parses as saying that the attacks are similar to a > CA, not the amount of hardening needed on the ACP registrar. Adding a > comma would probably help. fixed. > The ACP It is designed to enable automation of current network > management and future autonomic peer-to-peer/distributed network > > s/It // fixed. > Attacks from impacted ACP nodes against the ACP are more difficult > than against the data-plane because of the autoconfiguration of the > ACP and the absence of configuration options that could be abused > that allow to change/break ACP behavior. This is excluding > configuration for workaround in support of non-autonomic components. > [...] > The ACP acts as a security (and transport) substrate for GRASP inside > the ACP such that GRASP is not only protected by attacks from the > outside, but also by attacks from compromised inside attackers - by > relying not only on hop-by-hop security of ACP secure channels, but > adding end-to-end security for those GRASP messages. See > Section 6.8.2. > > This is true, but the system as a whole still has the weakness that the > compromised node is able to announce GRASP objectives for arbitrary > services and potentially cause legitimate traffic to be directed towards > it. The connection would still validate (until the certificate > expires or is revoked) and the attacker could return bad data that > causes honest nodes to misbehave. Yes. For non-autonomic networks such as those we target via rfc8368, i think we can most easily solve this problem easily via cert bits for Roles (A.10.5), so only NOC equipment can announce services. Note that this was traditionally not a real issue which is why we didn't wanted to add all these aspects to certs initially: you would have a real hard time to get new attack software into a typical legacy HW network infra. You'd have to attack by adding new hardware that has the software. Of course, in the last 5 years (after we started this *sigh*) network infra components become a lot more like PCs, so adding software becomes easier and hence also attacks from such software. And i fear that even though secure boot etc. exists, the security chains there are not necesssarily very strong. More fully distributed, self-organizing "Autonomic" solutions of course will be tougher. I would be happy if we can show that the security shell provided by the ACP and secure router platforms would be strong enough that there is enough room for starting to deploy more distributed services management without necessarily having to figure out upfront how to build self-organizing higher levels of security such as through self-learning reputation sccoring or the like. There is just a difference between what would be fun to do, and what i as an operator would be willing to accept as baked enough at any point in time ;-) > revocation and non-renewal of short-lived cdrtificates. In this > > nit: "certificates" fixed. > Section A.6 > > In my opinion, a lot of this could be split out into a separate draft > (that need not be published as an RFC) and just a couple paragraphs left > here with a pointer to that separate draft. But this is only a > Comment-level point, and I do not insist on it. Hah. In the other reply i gave you i think i referred to this text as already removed, but i forgot that the idea was to remove it before publication. So now i added the two notes to the top of this section: [RFC Editor: This section to be removed before RFC. [This section kept for informational purposes up until the last draft version as that would be the version that readers interested in the changelog would also go to to revisit it.] E.g.: I think its hard to justify putting more time (like separate RFC) into something that should be called "leftover ramblings from when we worked out the ACP, that we really should not forget". Going up to last draft seems like a low-cost compromise. Btw: Its nice you didn't say this is crazy, because as i mentioned in the other mail, the WG conclusion was that this type of multi-stage negotiation would be way too complex (hence also the removal). ;-) > Section A.7 > > An ACP domain is the set of all ACP nodes using certificates from the > same CA using the same domain field. GRASP inside the ACP is run > across all transitively connected ACP nodes in a domain. > > It's not entirely clear to me that we need to insist on a single shared > CA; given our discussion of potentially joining two distinct ACT domains > into a combined network, it seems that we just need to have all nodes > using the same set of trust anchor(s), which could potentially include > multiple CAs. (There would of course need to be some out-of-band > mechanism to avoid address-assignment collisions, which could be as > simple as rsub.) "from one or more Trust Anchors (TA) (typically one CA)" > Section A.8 > > For example, Intent could indicate the desire to build an ACP across > all domains that have a common parent domain (without relying on the > rsub/routing-subdomain solution defined in this document). For > example ACP nodes with domain "example.com", "access.example.com", > "core.example.com" and "city.core.example.com" should all establish > one single ACP. > > It is interesting to see this discussion in the context of the text in > the previous section about """If different ACP domains are to be created > [...] Domains "example.com" and "research.example.com" are separate > domains if both are domain elements in the domain information element of > certificates.""" Because this document doesn't intend to fnish working this out, its in appendices ;-) > Section A.8 > > There still feels like a lot of speculative things in here; I'd suggest > adding a disclaimer/introduction at the top that "Intent is the > architecture component [...]. Its applicability for use is quite > flexible and freeform, with potential applications including:" Its applicability for use is quite flexible and freeform, with potential applications including policies flooded across ACP GRASP and interpreted on every ACP node. i like "flexible and freeform" as a euphemism for "unclear, undefined and ongoing contentuous" ;-)) But yes, once we come up with specific policies we want to get standardized, we'll figure out a fitting way to do it, and thats what we then call Intent ;-) > Section A.9 > > Some solutions may already have an auto-addressing scheme, for > example derived from existing unique device identifiers (e.g., MAC > addresses). In those cases it may not be desirable to assign > addresses to devices via the ACP address information field in the way > described in this document. The certificate may simply serve to > identify the ACP domain, and the address field could be empty/unused. > The only fix required in the remaining way the ACP operate is to > define another element in the domain certificate for the two peers to > decide who is Alice and who is Bob during secure channel building. > > I think we need to mention this requirement for tiebreaking earlier in > the document, when we introduce the possibility of a certificate with > ACP address of '0'. The "0" address ACP nodes are not allowed to build secure channels, they are for ACP-connect'ed nodes in the NOC (i added that explanation through the reply to your first review email). The ++ = no-address ACP addresses are the ones that this spec does not define but supports interop with (by defining the address format). Added to the channel selection text in 6.5: A peer with an empty ACP address field in its ACP domain certificate becomes Bob (this specification does not define such peers, only the interoperability with them) In other words: I do not know nor care yet how to decide on Alive vs. Bob when both peers have no ACP address in their certificate. Subject to future work. > Section A.10 > > nit: the section title uses "futures" as a standalone term synonymous > with "future work"; unfortunately, "futures" is already an English word > with a quite distinct meaning. Changed to: "Further (future) options" I could sell you some A.10.7 options, sure they will go up in value ;-) (is that what you meant ?). > Section A.10.7 > > 1. Consider if LLDP should be a recommended functionality for ANI > devices to improve diagnostics, and if so, which information > elements it should signal (insecure). Includes potentially new > information elements. > > I'd suggest changing the parenthetical to "noting that such information > is conveyed in an insecure manner)". Fixed. > 3. The IDevID of BRSKI pledges should be included in the selected > insecure diagnostics option. > > In some environments (not really the current target case of Enterprise > networks) the IDevID would be considered privacy-sensitive, which may be > worth mentioning again here. Hmm. i went with a security example (which is arguably one reason for the desire of privacy, but i think many readers would associate privacy mostly with humans, so would be harder to read by some): This may be undesirable when exposure of device information is seen as too much of a security issue (ability to deduce possible attack vectors from device model for example) I also added a similar note to the end of the paragraph in 6.1.1 about certificates: Any other field of the ACP domain certificate is to be populated as required by or desired by the operator of the ACP domain ACP registrars/CA and required by other purposes that the ACP domain certificate is intended to be used for. For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID into the ACP domain certificate, such as the "serialNumber" (see section 2.3.1). Inclusion of this information makes it easier to potentially attack the node though, for example by learning the device model, which may help to select a fitting subset of attacks. Neighboring attackers can retrieve the certificate through an otherwise unsuccessful initiation of a secure channel association. > Section A.10.8 > > Ensuring that manaement sessions using invalidated credentials are > > typo: "management" Fixed. From nobody Mon Jul 22 16:23:55 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53530120094; Mon, 22 Jul 2019 16:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Hf9B22SIDmQH; Mon, 22 Jul 2019 16:23:52 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8503120048; Mon, 22 Jul 2019 16:23:52 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5AED3548066; Tue, 23 Jul 2019 01:23:48 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 54EA8440041; Tue, 23 Jul 2019 01:23:48 +0200 (CEST) Date: Tue, 23 Jul 2019 01:23:48 +0200 From: Toerless Eckert To: mcr+ietf@sandelman.ca Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20190722232348.quiofmmlg3ku64df@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Mcr changes for draft-ietf-anima-autonomic-control-plane-19 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:23:54 -0000 --- Context: -> This is the last set of changes integrated into -20. -> The diff for the changes discussed in this email is: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.4.txt They are also summarized under section (4) of the -20 changelog. -> The total changes -19 to -20 are of course: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt --- Reply: Michael, *: Sorry, i am still not a native github speaker and completely overlooked the textual improvement you made in March before IETF104. It was a bit of a trouble trying to up-rev them after i had already done all the other -19 review, but maybe one of these days i will catch those github-only notifications. Also integrated the proposed fix for HTTPs for EST connections. Wrt cleaning up older documents on github: Thats nice, but please keep the .19.x.txt versions as i have included those into the rfcdiffs of the changelog in the draft (as above). Cheers Toerless From nobody Mon Jul 22 20:08:43 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4F6120047; Mon, 22 Jul 2019 20:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kaeudVCtHzn6; Mon, 22 Jul 2019 20:08:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EC41200BA; Mon, 22 Jul 2019 20:08:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B99AF548014; Tue, 23 Jul 2019 05:08:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A8E49440041; Tue, 23 Jul 2019 05:08:29 +0200 (CEST) Date: Tue, 23 Jul 2019 05:08:29 +0200 From: Toerless Eckert To: Alissa Cooper Cc: The IESG , draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190723030829.3syv2aovinyy5ffz@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153313873429.21703.8495153083509673746.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Alissa: Re: Alissa Cooper's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 03:08:40 -0000 Hi Alissa Checking through my backlog, i see that your DISCUSS on the ACP -16 rev from 08/01/2018 is still in datatracker. Appended again the response to resolve all issues from those discuss/comments which i had sent originally on 08/08/2018, original Msg-ID <20180808023348.7j4k32dlt4cmzmna@faui48f.informatik.uni-erlangen.de> I had also sent a reply to Elwyn's GenART review which you refer to in your comments. Also sent on 08/08/2018. Fixes to his review where also included in the diff from -16 -> -18 (same as for your comments). That mail is also appended below under ==== Elwyn Sorry for me not notifying you earlier. Thanks Toerless ===== Original reply to Alissa: Sorry, too many typos in -17 to wait for next mayor fix version. had to rev to -18 *sigh* Thanks, Alissa Changes for your review have been committed together with changes for Elwin's review. into just posted -18 rev of the doc. rfcdiff here: http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-18.txt I hope this resolve all the issues you raised, give or take the postponed formatting asks i wanted to push off to RFC editor as they are tooling related). point by point replies inline below. Cheers Toerless On Wed, Aug 01, 2018 at 08:52:14AM -0700, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 6.10.4: > > "The value of the Interface Identifier is left for future definitions." > > I don't understand how this is usable without some definition. I.e., if I > assign every interface ID in my ACP to be 0, it's not going to work. Could you > elaborate about what is expected in this field? Thanks. This sentence was an overlooked leftover from before i added the whole section 8.1 (ACP connect), which is where the setup in which these addresses are used is defined/standardized. I replaced the sentence in question with: | Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See for details. 8.1.3. says normal IPv6 manual or preferrably SLAAC autoconfiguration of the interface identifiers, but really focusses on the RFCs to automatically learn prefixes through IPv6 RD, because that is the most important part of a LAN connecting to the ACP. Nothing new. Just a hopefully good profile of the most popular IPv6 autoconfig options. [ I'll respond to Brians proposal for specific stable addressing separate on the thread he opened.] Note that i did fixed up other text in conjunction with this discuss and the discussion below about the requirement to have or not to have the ACP address in the ACP domain certificate. These changes have the following result: The ABNC syntax for acp-address in the certificate allows a full ACP addres (32hex digits), no acp-address at all, or a placeholder address "0". The text changes make this work and explain it: - ACP nodes get a 32bit hex-digit - Non ACP-channel capable nodes, like NOC equipment gets an empty acp-address field. they use the manual ACP addresses, but given how those use traditional assignment methods, those are not managed by the registrar. Those nodes can still use their ACP certificate for any end-to-end authenticartion, just not to build ACP channels. - (future) ACP nodes that have some other method to assign their ACP address beside getting it through the certificate use "0". Thats the indication from the registrar that those nodes are permitted to build ACP secure channels, but did not get their address from the Registrar(s). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > FIXED: > General: > > Please address the Gen-ART reviewer's latest round of comments. See separate reply. ------------------ > FIXED: > There are a bunch of places in this document where it seems like there is a > tension between specifying a limited set of functionality here and being able > to support a wider variety of deployment scenarios. This is noted in Section 1 > but I think in general it would be clearer if uses of the term "future" > throughout the document could be more surgical as well as more specific about > whether they mean "people might deploy this differently in the future" or > "standards would need to be developed in the future." > I've made a few > suggestions about some of these turns of phrase below but would suggest someone > do a full edit pass with this in mind because there are a large number of > mentions of "future work." Of course there is always more work to do, but every > bit of "future work" need not be mentioned in this document, and in cases where > it is mentioned I think there should be a specific reason for doing so that > bears on people implementing this specification. I don't think this fits in the > DISCUSS criteria but for a document that intends to be published on the > standards track I would expect it to be crisper about the dividing line between > the normative behavior being specified here versus changes or extensions that > may or may not be made in the future. Let me answer in 5 points: 1. All relevant sections have "Normative" vs. "Informative" in their title. added "Informative" to sections where it was missing. Modified section 4: Requirements": Informative - ask from AD was not to have separate use-case/requirements document in charter round 1, so the use-case/requirements sections here are really only the input to the specification. The words in 4./Requirements are now _MUST_, _SHOULD_ to set them apart from rfc2119 and text explains it (i can change to any other preferrable syntactic differentiation). 2. Normative MUST/SHOULD are only in the normative sections. 3. Introduction also summarizes which sections are normative and which informative. I fixed up the text in the intro to be more complete wrt. to that. | The normative part of this document starts with | where the ACP is defined in detail. | defines normative how to support ACP | on L2 switches. explains normative how | non-ACP nodes and networks can be integrated. | The remaining sections are non-normative:... Also added sentence to introduction: | There are no dependencies against Appendix A to build a complete working and interoperable | ACP according to this document. 4. Eliminating gratuitous future - primarily from normative text. I have tried as good as possible to eliminate "futures" from the normative section (6...8,10). Here is a list of the changes except for the mayor ones you inquired about separately be low: 1) | See for discussions about how variations | of the ACP could be defined in the future (standard or proprietary) | to better meet different expectations from those on which the current design is based In informative section (applicability statement), forward pointer to A. I added "(standard or proprietary)" to be clearer. I insered this sentence because there where over the course of the WG work a lot of discussion about how to do things differently, the gist of it is in appendix A, so this is just a forward pointer. 4) | Connecting over non-ACP Layer-3 clouds requires explicit configuration. | See . | This may be automated in the future through auto discovery mechanisms across L3. Ok, this "future" is pretty gratuitous without explanation. Removed. 5) | Other uses are subject to future work, but it is recommended that | it is the default security check for any end-to-end connections | between ASA. It is equally useable by other functions such as | legacy OAM functions. Removed, refined first sentence of paragraph to hopefully be well inclusive of any such future work: | The ACP domain certificate SHOULD be used for any authentication | between nodes with ACP domain certificates (ACP nodes and NOC nodes) | where the required condition is ACP domain membership, such as ACP | node to NOC/OAM end-to-en security and ASA to ASA end-to-end security. 6) | extension = ; future definition. This is in the ABNF of the certificte extension specification, and that spec needs a hook to support for future definitions. 9) DELETED: | Future work optimizations could avoid this but it is unclear how | beneficial/feasible this is replaced with: | which has the following benefits: 10) DELETED: | If a node learns through a future autonomic method or through configuration that it is part of a zone replaced with: | If a node learns (see ) that it is part of a zone (auto-aggregation subsection is one of two new A. sections created in rely to this DISCUSS, see below). 11) DELETED: | (subject to future work) (in zone-id explanationt ext) no replacement (gratuitous). 12) DELETED: | Future work may define mechanisms for auto-coordination between ACP nodes and auto-allocation of Subnet-IDs between them no replacement (gratuitous). 14) IMPROVED: Future is used to explain the semantic of the "objective-value" in the SRV.est GRASP objective. I fixed up the text to be more precise: | Objective-value MUST be ignored if present. Backward compatible | extensions to MAY be indicated through | objective-value. Non compatible certificate | renewal options MUST use a different objective-name. 15) 6.11.1.1- moved notion about future improved RPL option (for multiple NOC) into appendix A 16) 6.12.2 - remove "future" from wording of performance through rewording (this is really just a matter of impleemntation choice, applicable to both first-generation or future geneation implementations, so no need to talk about futures. 17) 6.12.5 "future protocols". Just refined wording, but kept it unchanged. The reason to use the word "future" here was solely to emphasize on the independence of the described mechanisms, but not to suggest future work: | Any type of ACP secure channels to another ACP node can | be mapped to ACP virtual interfaces in different ways. | This is independent of the choosen secure channel protocol (IPsec, DTLS | or other future protocol): 18) 8.1.1 "ACP connect security: removed notion of future work, but instead gave an example that could be impleemtned without future (work outside the scope of this spec), and moved the suggestion that would require future standards work (using ACP spec extension) into A.10. 19) 7.2 - removed senetence with notion of future (MacSec) - gratuitous. 20) 8.1.2 - removed sentence with future. This was just describing interla implementation options, so that work wold be in scope of implementations of this spec, no need to call it futures. 21) 9.2.2 (informative section). Removed notion of future role based security. This is not one paragraph in A.10 22) Removed notion that we need a YANG data model (future work) for ACP/ANI Obvious enough so we will not forget even without this note. Overall: In the few places where i have kept "futures" in the normative text, i did try tou be explicit about "standard vs. non-standard" futures. In summary: there should now be close to minimal possible instances of "futures" in the normative text. I hope for this document this will suffice. 5. Futures discussion in section A: Note: Half of A. is futures, the other half is explanations. The futures where the part of the WG time we spent but concluded it was too much work to put into the current spec, but we hink it is crucial not to loose this work. (I have seen so many IETF standards RFC where this actual WG work context isn't kept but thrown out, and 10 years later the few people left with institutional memory have to re-explain the stuff, but why doc made decisions, and also what was seen as next steps). ------------------ >FIXED: > "Intent" is used both capitalized and in lower case throughout the document and > I'm unclear if this is meant to signify a distinction or not. Thanks. 3 occurances of intent -> Intent. ------------------ > POSTPONED/RFC-editor: > Section 2: > > Please remove the -->"..."() notation. Discussed in prior review, but the outcome ended up only in changelog. I've now inserted the following note on top of section 2 to avoid further comments on this: [RFC Editor: WG/IETF/IESG review of the terms below asked for references betwen these terms when they refer to each other. The only option in RFC/XML i found to point to a hanging text acronym definition that also displays the actual term is the format="title" version, which leads to references like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate the trailing '()' generated by this type of cross references. Can you please take care of removing these artefacts during editing (after conversion to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. ------------------ > FIXED: > Please use the exact boilerplate from RFC 8174, not a variation. Thanks. i copied the text from what an earlier reviewer suggested. Must have come from RFC8196. Only RFC with that mistake (says google). > It seems like RFC citations should appear for IKEv2 and DTLS upon first use in > this section. Otherwise, it seems they are first cited at different future > points in the document (Section 6.3 and 6.7, respectively). Yepp. applicability section was added late, forgot to fixup first references. ------------------ > FIXED/NEW TEXT: > Section 3.3: > > "The ACP provides reachability that is independent of the Data-Plane > (except for the dependency discussed in Section 6.12.2 which can be > removed through future work)," > > Isn't this kind of a big exception, given that there is meant to be a secure > channel between pairs of nodes in the ACP and that developing future > encapsulations is non-trivial? It seems like phrasing this the other way around > (the ACP is dependent on the Data-Plane for but is otherwise independent > of it) would be more accurate. Nice! Thanks a lot to have me reconsider this text. This text is wrong because it is elevating limitations of the implementation of ACP that i helped build and am familiar with to limitation of the spec standard. So sometimes, knowing too much code doesn't help writing a spec *sigh*. Text changed to: | Depending on the implementation (see | for more details), the ACP provides reachability that can be | independent of the Data-Plane. This allows the control plane and management | plane to operate more robustly. "general_addressing" 6.12.2 (informative) text is fixed up to explain the candidate implementation issues better than in -16: | To avoid that Data-Plane configuration can imact the operations of the | IPv6 (link-local) interface/address used for ACP channels, appropriate | implementation considerations are required. If the IPv6 interface/link-local | address is shared with the Data-Plane it needs to be impossible to unconfigure/disable | it through configuration. Instead of sharing the IPv6 interface/link-local | address, a separate (virtual) interface with a separate IPv6 link-local | addresss could be used. For example, the ACP interface could be run over a separate | MAC addres of the underlying Ethernet type interface. For more details and options, | see . I added "A.10.2. Removing IPv6 data plane dependency" to further detail implementation options, and also one possible future that would require additional specification (different ethertype). The reason for regurgitating on this point i that its really the most difficult part of an implemenation if you want to be independent of the data plane. ------------------ > UNCHANGED/EXPLAINED: > Section 6: > > "Indestructible" seems like an overstatement. Maybe "resilient" would be more > accurate? As written, the ACP is meant to be resilient and indestructible. We use resilient to describe the ability to recover (from errors/attacks). This applies mostly to the network side (common property of most our routing stuff), but also with the Cert security system (revoking membership after nodes become compromisedetc.). We use indestructible to indicate the absence or reduction of an "attack surface". For example that ACP is defined to use clearly separated infra that would have only ReadOnly YANG models - no way to misconfigure. Or just ~3 UDP ports you could attack from the network (GRASP and IKEv2/IPsec). Aka: minimied atck surface from the network. Unattackable was a choice, but the biggest concern is friendly fire from erroneous peers, operators or SDN controllers without malicious intent. Therefore we concluded on indestructible. ------------------ > FIXED: > Section 6.1.1: > s/Such methods are subject to future work though./No such methods have been > defined at the time of publication of this document./ I fixed this text also in response to a discus from you below to make it clear when the acp-address is optional (for peers, not for ourselves). | Nodes complying with this specification MUST receive their ACP address | through the domain certificate, so their own ACP domain certificate MUST | contain the "acp-address" field. Nodes complying with this specification | MUST also be able to authentice nodes as ACP peers that have determined | their ACP address differently and whose ACP domain certificate may therefore | NOT have the "acp-address" field. See for further discussions. ------------------ > s/to build ACP channel/to build ACP channels/ ACK ------------------ > s/that intends to be equally unique/that it intends to be equally unique/ ACK ------------------ >FIX/CHANGED TEXT: > ""rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP." > > What is the point of defining this now when it is unclear if or how it will be > used? There are already means for nodes to do error handling, so it seems like > defining a new field in the future if/when it is needed would work fine and be > cleaner. Appendix A.7 seems to assume some semantics for this field, which > makes the way it is specified here even more confusing IMO. Yes, that text was unnecessarily alluding to unresolved future issues when there is no need to do so because there are perfectly good use-case reasons to have rsub now and how to benefit from them now - without extensions. Texts fixed to: | "routing-subdomain" is the autonomic subdomain composed of "rsub" | and "acp-domain-name". "rsub" is optional. When not present, | "routing-subdomain" is the same as "acp-domain-name". "routing-subdomain" | determines the /48 ULA prefix for ACP addresses. "rsub" therefore allows | to use multiple /48 ULA prefixes in an ACP domain. | See for example use-cases. And that A.7 example is improved to: | The rsub element in the domain information field permits the use of addresses | from different ULA prefixes. One use case is to create multiple physical | networks that initially may be separated with one ACP domain but different | routing subdomains, so that all nodes can mutual trust their ACP domain | certificates (not depending on rsub) and so that they could connect later | together into a contiguous ACP networks.One instance of such a use case is an ACP for regions interconnected | via a non-ACP enabled core, for example due to the absence of product | support for ACP on the core nodes. ACP connect configurations as defined | in this document can be used to extend and interconnect those ACP islands | to the NOC and merge them into a single ACP when later that product | support gap is closed. Auto-aggregation is now only discussed in new section A.10.8.2 ------------------ > FIXED/CHANGED-TEXT: > "In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus > characters are necessary so the node can unambiguously parse that > both "acp-address" and "rsub" are empty." > > This seems contradictory. Either "acp-address" is REQUIRED in which case there > are no exceptions, or it's not; if it's not, then the expected syntax for cases > when it's not present should be specified. Thanks. Took me a while to understand i was talking about semantics and you about syntax. Fixed text accordingly. NOdes in this spec MUST have acp-address in their own cert, but must also recognize peer certs as valid without acp-address in the peers cert: | Nodes complying with this specification MUST be able to receive | their ACP address through the domain certificate, in which case | their own ACP domain certificate MUST contain the "acp-address" field. | Nodes complying with this specification MUST also be able to authenticate | nodes as ACP peers that have determined their ACP address differently | and whose ACP domain certificate MAY NOT have the "acp-address" field. | See for further discussions. ------------------ > Section 6.1.2: > > s/If the node certificates indicates/If the node certificate indicates/ ACK ------------------ > FIXED/ADDED TEXT: > Section 6.3: > > It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Yes. The reason is that for once IPsec/IKE is important and proven and intended to be the primary protocol, and for non-security folks the naming might be somewhat confusing (IKE vs IPsec), and the whole options with without GRE and IKE able to autoselect this etc. Hence the explanations. But i added a boring sence about DTLS for equal treatment: "DTLS" indicates datagram Transport Layer Security version 1.2. There is no default UDP port, it must always be locally assigned by the node. See . Note that there is already "6.7.2. ACP via DTLS". ------------------ > FIXED: > Section 6.4: > > This is a good example of a section where the blurring between the specified > behavior and expectations for the future is unhelpful IMO. Why specify the > current default and then spend a lot of words (including Appendix A.7) talking > about how it will be different in the future? I have moved all the 6.4 Intent stufff into new section A.8 and also moved the Intent stuff in A.7 into A.8 to clean up. We did spend a lot of time in the WG to discuss the Intent issues, and i think that the little whats now left in A.8 is relevant documentation for possible future work that would otherwise get easily lost, so do not want to delete it completely. ------------------ > Section 6.10.3.1: > > s/We do not think this is required at this point/This is not currently required/ ACK ------------------ > Section 6.12.2: > > s/may specify additional layer 2 or layer encapsulations/may specify additional > layer 2 or layer 3 encapsulations/ (I think?) ACK ------------------ > Section 8.2.1: > > This seems extraneous: "Future work could transform this into a YANG > ([RFC7950]) data > model." ACK. ------------------ > Appendix A.8: > > "Secure channels may > even be replaced by simple neighbor authentication to create > simplified ACP variations for environments where no real security is > required but just protection against non-malicious misconfiguration." > > I think experience has shown that even environments where it is assumed that > security is not required prove to need it. I would suggest removing this text > or changing this implication. Yes, and again this was badly written text, the future option in mind wasn't meant to be insecure anyhow *sigh*: Sentence left for that suggestion is: | ACP hop-by-hop network layer secure channels could also be replaced | by end-to-end security plus other means for infrastructure protection. Note again, that we have been trying to make sure that all the text in this section A is not unsolicited but really the result of repeated questions/ requests in the WG to do things like this (or explains reasons for decisions in ACP). That one sentence for example goes back to the fact that the hop-by-hop encryption has been the biggest challenge to product adoption of ACP. ------------------ Impressed that you got all the way down to A.8. Thanks a lot! ===== Elwyin >From tte@cs.fau.de Wed Aug 8 01:26:44 2018 Date: Wed, 8 Aug 2018 01:26:44 +0200 From: Toerless Eckert To: Elwyn Davies Cc: gen-art@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Subject: Re: Genart telechat review of draft-ietf-anima-autonomic-control-plane-16 Message-ID: <20180807232644.5avcaxrnrt2phz3o@faui48e.informatik.uni-erlangen.de> References: <153308194697.3384.1689302422182872423@ietfa.amsl.com> In-Reply-To: <153308194697.3384.1689302422182872423@ietfa.amsl.com> Thanks a lot Elwyn Changes for your review have been committed together with changes for Alissa's review into just posted -17 rev of the doc. rfcdiff here: http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-17.txt I hope all the issues you raised ahve been resolved. Point by point replies inline. Cheers toerless On Tue, Jul 31, 2018 at 05:05:47PM -0700, Elwyn Davies wrote: > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-anima-autonomic-control-plane-16 > Reviewer: Elwyn Davies > Review Date: 2018-07-31 > IETF LC End Date: 2018-02-26 > IESG Telechat date: 2018-08-02 > > Summary: > This document is ready but has a fair number of nits still to fix, particularly > in the earlier part of the document. There are also some language issues to > address which the RFC Editor will deal with. My issues from the Last Call > review have been addressed. > > Major issues: > None > > Minor issues: > None > > Nits/editorial comments: > General: There are three remaining examples of "intent" rather than "Intent". ACK > General: There are five instances of the construction -> "quoted text" () in > s2. Need to remove -> and () in each case. This may be down to tool problems - > there is a comment in the revisions list. DEFERRED, added instruction to text: [RFC Editor: WG/IETF/IESG review of the terms below asked for references betwen these terms when they refer to each other. The only option in RFC/XML i found to point to a hanging text acronym definition that also displays the actual term is the format="title" version, which leads to references like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate the trailing '()' generated by this type of cross references. Can you please take care of removing these artefacts during editing (after conversion to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. > S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/ ACK > s1, para 5: s/The details how this achieved are defined in Section 6./The > details of how this achieved are described in Section 6./ ACK (also added "is" after "this". > s1, bullet point #1: s/supports directly/directly supports/ ACK > s1, bullet point #3: s/network/(Data-Plane) network/ > S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style > automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/ ACK > S1.1, para 2: Operational Technology is a term that is not very well-known - a > reference would help. Unfortunately it seems that the text of ISA99 that > defines the term is not freely available. Suggestions of a freely available > alternative? Added xref to terminology section, added term to terminology section, used Wikipedia URL and first line description from it : "The hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, etc". OT networks are today in most cases well separated from Informationn Technology (IT) networks. > s1.1, para 3: Although RPL is in the glossary in s2, this instance occurs > before s2 is announced, so it would be worth adding RPL (Routing Protocol for > Low-power and Lossy Networks - RFC6550) ACK > s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain > certificate". See above. I specifically added "->" because thats whats typically done in other terminologies when there is a reference to another term. > S2, "ACP Domain": 'of nodes with ->"ACP domain' . Remove "->" and ()? Likewise. I have tried to find some better examples of cross-references between words in a terminology section of an RFC, but couldn't find any. Aka: lets RFC editor figure it out and/or Hendrik via tooling and trac case. > s2. "ACP Loopback interface": Need to expand VRF on first use. ACK > s2, "ACP secure channel": As wrtten this equates a security association with a > secure channel. Suggest: NEW: ACP secure channel: A sequence of links > established hop-by-hop between adjacent ACP nodes with a security association > established for each link using the ACP secure channel protocol and the ACP > Domain Certificate. The channel is used to carry traffic of the ACP VRF > separated from Data-Plane traffic in-band over the same links as the > Data-Plane. ENDS Ok, got the point that the channel is not just an association but the actual data channel, but your suggestion was binding the term to a sequence of links, which i think is wrong too. Replaced now with: A cryptographically authenticated and encrypted data connection established between (normally) adjacent ACP nodes to carry traffic of the ACP VRF secure and isolated from Data-Plane traffic in-band over the same link/path as the Data-Plane. > s2, "Data-Plane": s/non-autonomic/by means other than autonomically/ ACK > s2, "GRASP": s/required/REQUIRED/ I have refrained from considering the terminology section to be normative so far because i don't think i have ever seen this being done in other RFCs, so i am only using those uppercase words in the normative sections. Let me know if you disagree. > s2, "in-band (management)": fix up two instances of -> ... (). see above. > s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to > s6.10.5 hasn't been translated. ACK > s2, "(virtual) out-of-band network": fix up one instance of -> ... (); see above > s/where historically/were historically/; In next to last sentence s/out of > band/out-of-band/ ACK > s2, "ULA": s/are the first 48 bit/is the first 48 bits/ changed to "are the first 48 bits" > s2, "(ACP) Zone": s/protocols details/protocol's details/ ACK > s3.1: s/This way/In this way/; possibly s/other processes/single instamces of > other processes/??? ACK > s3.2, last para: s/like/such as/ [like: Yuck!] ACK *yikes* several of these sneaked into the text, tried to eliminate all of them.. > s3.3, para 1: s/managment/management/ ACK > s3.3, first bullet: s/out of Band/out-of-Band/ Actually now using consistently out-of-band > s4, ACP2: The phrase "(can block easily at edge)" needs additional explanation. Changed to "infrastructure security (filtering based on known address space)". > s4, ACP4: s/generic. Usable/generic, that is it MUST/ ACK. > s4, last para: Need to expand eACP. s/Th eACP/The ACP/ ;-) > s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/ Text changed due to Alissas discuss. > s5, lata para: s/This way/In this way/ ACK > s6.1, para 4: Trailing colon s/b period. ACK > s6.1.1, last para on page 20: s/":" are not/The character ":" is not/ ACK > s6.1.1, last but 2 para: s/information element it,/information > element,/(probably) ACK > s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers > domain/peer's domain/ ACK > s6.1.3.1, last para: Expand ttl on first use. ACK > s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain > certificate/; s/nodes ACP/node's ACP/ ACK > s6.3, para 2: s/State Less/Stateless/ Actually StateLess as its used to expand SLAAC > s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with > reasonably fast/ ACK > s6.12: s/hop by hop/hop-by-hop/ ACK > s8.2.1, bullets 2 and 3: s/vrf/VRF/ ACK Many thanks again! From nobody Tue Jul 23 10:31:20 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB33612063F for ; Tue, 23 Jul 2019 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1cXHq4qnFmfQ for ; Tue, 23 Jul 2019 10:31:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A72B12006B for ; Tue, 23 Jul 2019 10:31:16 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:1232:144:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id 6DE911F44B; Tue, 23 Jul 2019 17:31:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3E5151BBF; Tue, 23 Jul 2019 13:31:36 -0400 (EDT) From: Michael Richardson To: "Mendelson\, Tsippy" cc: "tte+ietf\@cs.fau.de" , "anima\@ietf.org" , "Ruan\, Xiaoyu" , "Jayanna\, Prabhu" , "kwatsen\@juniper.net" , "Michael.H.Behringer\@gmail.com" In-reply-to: <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> Comments: In-reply-to "Mendelson, Tsippy" message dated "Tue, 23 Jul 2019 09:26:54 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 23 Jul 2019 13:31:36 -0400 Message-ID: <13736.1563903096@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 17:31:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mendelson, Tsippy wrote: > Sending again to wider ANIMA audience =E2=80=93 as I received no resp= onse. I don't think that I saw it before. But, you posted to the list, which is the right place. (You could have opened a github issue) > We have identified a reference to an old spec in BRSKI draft > draft-ietf-anima-bootstrapping-keyinfra-22. > The draft refers to: > [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, > standard/802.1AR-2009.html>. > However there is a later spec: > https://standards.ieee.org/standard/802_1AR-2018.html > The specific quote from 802.1AR-2009 that we would like to ask about = is in > section 2.3.1 =E2=80=9CIdentification of the Pledge=E2=80=9D: So, I have no idea if 802_1AR-2018 is better or not, as I don't have a copy of it. I tried last week to get a copy of it via the getieee system, but I failed. I had previously been able to download the 2009 version. > The following fields are defined in [IDevID] and [RFC5280]: > =C2=A0 > =C2=A0=C2=A0 o=C2=A0 The subject field's DN encoding MUST include the= "serialNumber" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute with the device's unique ser= ial number.=C2=A0 (from [IDevID] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 section 7.2.8, and [RFC5280] section 4= .1.2.4's list of standard > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attributes) > In 802_1AR-2018 we could not find that the =E2=80=9CserialNumber=E2= =80=9D attribute > MUST be included rather we found SHOULD: Yes, but we are saying that *WE* require it.=20=20 > Here it says: An IDevID certificate subject field shall be non-null a= nd > should include a unique device serial number. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl03RHcACgkQlUzhVv38 QpAAmQf+KBxj+EYntJrw8eFRD3haBGV7FDymPbBkB7d3jqqIgbjmQv/VNIIAObGB x1GfMZSnshdNhmntuXXjqO/H335u7TmlogQrqSdsei+dbcNHkCJuqCm4Woggfu48 THC8MXH4y2hcqbi1fPgKFYP+n03XvrQlx0aJF6YgcqJtHoHkj8uW1lu1MVLtlZzz 8QJmqmNix1/bjIaT2mkL2pIADJI8PtZGA0LKn7g3NHAPjtn65g+mfKsHYEVR4waM cFPWUepVNDJcjaQIxDFS8Cm5gPt/unSIp8lVXZN9k84JkzoJNT+x1pDl5a/hjHaO XA8RQ2ymBx4z9qfRE6ZtvrJi/ONRxg== =m39e -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 24 15:00:23 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95A61202EC; Wed, 24 Jul 2019 15:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 860uF0aZwDJk; Wed, 24 Jul 2019 15:00:20 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B23120372; Wed, 24 Jul 2019 15:00:19 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 492FD54800E; Thu, 25 Jul 2019 00:00:15 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3839A440041; Thu, 25 Jul 2019 00:00:15 +0200 (CEST) Date: Thu, 25 Jul 2019 00:00:15 +0200 From: Toerless Eckert To: anima@ietf.org Cc: "Owen Friel (ofriel)" Message-ID: <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] FWD: ACME for devices side meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:00:22 -0000 Owen sent the following nice notes about the side meeting. Will comment separately. Bcc'ing the original recipients. On Wed, Jul 24, 2019 at 08:26:20PM +0000, Owen Friel (ofriel) wrote: > Minutes from today's meeting. > > General consensus that figuring out how to use ACME for issuance of device/client certs is a good idea > > There are (at least) three related drafts in this space > - draft-yusef-acme-3rd-party-device-attestation > - draft-friel-acme-integrations > - draft-moriarty-acme-client > > draft-moriarty-acme-client > - outlines several use cases for client and device certs > - as Kathleen could not make the meeting, we didn't discuss this in detail > > draft-yusef-acme-3rd-party-device-attestation and subsections of draft-friel-acme-integrations are trying to solve similar problems: > - leverage a cloud service to assist in ownership proofs for devices > - use ACME to issue LDevID certificates to devices > > draft-yusef-acme-3rd-party-device-attestation > - assumes devices have self-signed certs, not certs signed by a manufacturer private CA > - The BRSKI-ACME flow Rifaat presented uses a vendor default BRSKI registrar, and is a reasonable starting point for device's getting certs from ACME > - This flow is not currently documented in Rifaat's draft > - We can probably avoid the need for ACME to understand the vendor's JWT > > draft-friel-acme-integrations > - documents (partially) the BRSKI-ACME flow but uses a local domain registrar, not the vendor default registrar > > draft-ietf-anima-bootstrapping-keyinfra > - underspecifies how the MASA should handle Voucher Requests directly from the Pledge i.e. the Cloud Registrar use case > - Toerless suggests that this clarification could be a small standalone document > > No draft currently sufficiently specifies how the pledge/device should generate a CSR subject/SAN that will keep ACME happy > > The EST/BRSKI sections of draft-friel-acme-integrations, and draft-yusef-acme-3rd-party-device-attestation, probably need to be combined by a new draft > - if the device is going to use a self-signed cert, then how the EST RA validates device identity needs to be specified as this is a change from BRSKI > > The ACME subdomain use case needs to be split out from draft-friel-acme-integrations into a separate small document > From nobody Wed Jul 24 15:34:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970B71203B8 for ; Wed, 24 Jul 2019 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 doYVHjlFnD5i for ; Wed, 24 Jul 2019 15:34:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D86120110 for ; Wed, 24 Jul 2019 15:34:37 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5A95E54806A; Thu, 25 Jul 2019 00:34:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 49921440041; Thu, 25 Jul 2019 00:34:32 +0200 (CEST) Date: Thu, 25 Jul 2019 00:34:32 +0200 From: Toerless Eckert To: anima@ietf.org Cc: "Owen Friel (ofriel)" Message-ID: <20190724223432.ryydigwlh5gtiobw@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] BRSKI<->ACME use case (was: Re: FWD: ACME for devices side meeting) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:34:39 -0000 Some thoughts about draft-friel-acme-integration also after the ACME side meeting. Talking to Owen after ANIMA, he explained the use case for his draft, which would be great to include into a rev. At least i hope i wasn't the only one to whom it wasn't completely obvious even without being stated ;-)) The way i would desribe the use-case is this: You are an enterprise or home, you may have some BRSKI like infrastructure (cloud-based, local, whatever) that helps to auto-enroll any type of devices you want to use in your network, but: Many of these devices will have a web-server to access/control/use them, and when you access them via a browser there is the issue that web browsers will complain unless the device is enrolled with a certificate signed by a public PKI CA (in the browsers TA list) and can be used to authenticate the domain name the device is using. This is where ACME comes in because the key thing separating itself from EST is that it has the mechanisms so RA (registrars) can provide proof of ownership of a DNS domain/prefixes for which they can then request certificates. At least thats how i understood the explanation given to me. So, i would certainly welcome if we made sure BRSKI<->ACME can be made to work well. Another thing coming to mind: devices that have a web-server will support TCP, so they won't pose the problem of having to change the basic transport protocol to use for BRSKI, unlike the constrained "iot" devices, where we have to use protocols like CoAP. And given how we made sure that the ANI certificate pieces do not conflict with any type of certifictes attributes required for "web certificates", this should also all work well with not only BRSKI but even ANI (using certificates with the ACP rfc822Name). At least this would be my hope, and certainly something i would like to verify with ACME. Cheer Toerless On Thu, Jul 25, 2019 at 12:00:15AM +0200, Toerless Eckert wrote: > Owen sent the following nice notes about the side meeting. > Will comment separately. Bcc'ing the original recipients. > > On Wed, Jul 24, 2019 at 08:26:20PM +0000, Owen Friel (ofriel) wrote: > > Minutes from today's meeting. > > > > General consensus that figuring out how to use ACME for issuance of device/client certs is a good idea > > > > There are (at least) three related drafts in this space > > - draft-yusef-acme-3rd-party-device-attestation > > - draft-friel-acme-integrations > > - draft-moriarty-acme-client > > > > draft-moriarty-acme-client > > - outlines several use cases for client and device certs > > - as Kathleen could not make the meeting, we didn't discuss this in detail > > > > draft-yusef-acme-3rd-party-device-attestation and subsections of draft-friel-acme-integrations are trying to solve similar problems: > > - leverage a cloud service to assist in ownership proofs for devices > > - use ACME to issue LDevID certificates to devices > > > > draft-yusef-acme-3rd-party-device-attestation > > - assumes devices have self-signed certs, not certs signed by a manufacturer private CA > > - The BRSKI-ACME flow Rifaat presented uses a vendor default BRSKI registrar, and is a reasonable starting point for device's getting certs from ACME > > - This flow is not currently documented in Rifaat's draft > > - We can probably avoid the need for ACME to understand the vendor's JWT > > > > draft-friel-acme-integrations > > - documents (partially) the BRSKI-ACME flow but uses a local domain registrar, not the vendor default registrar > > > > draft-ietf-anima-bootstrapping-keyinfra > > - underspecifies how the MASA should handle Voucher Requests directly from the Pledge i.e. the Cloud Registrar use case > > - Toerless suggests that this clarification could be a small standalone document > > > > No draft currently sufficiently specifies how the pledge/device should generate a CSR subject/SAN that will keep ACME happy > > > > The EST/BRSKI sections of draft-friel-acme-integrations, and draft-yusef-acme-3rd-party-device-attestation, probably need to be combined by a new draft > > - if the device is going to use a self-signed cert, then how the EST RA validates device identity needs to be specified as this is a change from BRSKI > > > > The ACME subdomain use case needs to be split out from draft-friel-acme-integrations into a separate small document > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 24 16:03:26 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB28120103 for ; Wed, 24 Jul 2019 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FzTs-w7dj90z for ; Wed, 24 Jul 2019 16:03:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B31F1200FD for ; Wed, 24 Jul 2019 16:03:21 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id 186581F44B for ; Wed, 24 Jul 2019 23:03:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 07D831B00; Wed, 24 Jul 2019 19:03:42 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-reply-to: <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Thu, 25 Jul 2019 00:00:15 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 24 Jul 2019 19:03:42 -0400 Message-ID: <6709.1564009422@dooku.sandelman.ca> Archived-At: Subject: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 23:03:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I was asked to decode words mangled at the mic at Tuesday morning's ANIMA meeting. The word was "MACsec", and=20 https://en.wikipedia.org/wiki/IEEE_802.1AE https://1.ieee802.org/security/802-1ae/=20=20=20=20=20=20=20=20 provides a reasonable description, and probably the getieee mechanism might get you a copy for free, but IEEE doesn't have a URL that leads to the actual document. I did read it once. (One of the URLs in the wikipedia page leads to 404) https://ieeexplore.ieee.org/document/8585421 might get you the document if you have a valid password, which I used to, but apparently not anymore. Given my newly acquired understanding that MACsec applies on a per-port basis, not on a per-VLAN basis, this means that it would be rather difficult to do peer discovery and security for a L2-bridged LAN. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl04480ACgkQlUzhVv38 QpDumAf+N5xD8rvAeA6YfNX4F4p1tMmuWnyGzdEr/TybcwLvYxBJ7JUx+kI2GcmL hF9fj9MWIY4Ljykd763akJC+HQU4Ti5gYubabbWpJsndfCbswSRnnysvPG6mWPEM ob46i764gqeid/ozz4DY3ksRrCgfWZiRLojQ74batmhXgqEoIzup3HskyNLc5VV6 jGX/NQScmEuYN3XCDnBzR+RfUkQ7iyd7TtPm7qrBcx2KQS+d0WY1Mn5MftvLfMmS pc5Zf05o4hjSfVY8EmmfTM5gIPTdKhyf/3kxMnHiUm58VDKW2QCDMXOheKFVLQ8i BAa3Y6SVaQLXDJitXOHSUEjL284JrA== =FVBi -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 25 07:29:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3CC1201D8 for ; Thu, 25 Jul 2019 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AT7Vk7KJcH3Q for ; Thu, 25 Jul 2019 07:29:02 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE99E1201B7 for ; Thu, 25 Jul 2019 07:28:57 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id x22so44326661qtp.12 for ; Thu, 25 Jul 2019 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bFVFkZ3K0EFZsQPBm8DxZoJ+p04TAjwbeSLijH8+v2g=; b=tXZfPxPTZKTkZmUYNMRCx4pQm9JnT7ldXmoDj9QTM/0korml+asPOOe07KbBBKfjZ9 3RZMCWpetH7XxJi8r1RMH4Y8irisvY57S9PRW/WYQVdCA8R2DrpCxaTnPbNJNU3QiIo5 TIoFCwxLk0PrW1LCsfucL2I/xNZv6MlrH0Qv2tuYHr7HFDT/sxydtb/16CDL2RgOF/RR Gr/actiR1BP3J84ycWeFUhniagsCWgT2f+2P9ax4lTgw6U4r48a4xXGX9NqMLr1sc8DE /97olmCNbJNqsGY3UOrQQ6oWonXRotT4iVANh5qcxSkW3PGLipPtqkWjnxTVjOtvFLd0 jdpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bFVFkZ3K0EFZsQPBm8DxZoJ+p04TAjwbeSLijH8+v2g=; b=Nvh9QZLi6HHg4MxM9bd649RNHto3+AykVud0gh5rHDIohD5uU2CK14AMeQU3vesCes 8k316Jcznoj2wg07sPLciMkcBEY64TcuoBT3sGjmNkpQKPuxxoVsUcLAdIJa2LVmlPzP RlWArnSoqvjLdr3t/6R31o1bwZNm8rWQderR7BwizsuXgLHKkURsfkk2djTZbSMiVCyG M+uZLIkyd0XJ+Fs416LUyc3FV6+XQPIRf4RkbESy4LQCN37FuFNFe/Uj+dY+PlMLwqjp pdux0Km+QLkmt/GiTfz+JFGmS/FgCTSvPjOwftgcdLbwrzN5MwdRK6sHsNdsxqUhght7 uBMQ== X-Gm-Message-State: APjAAAU+tMNSImU6lRHuh4L4tLJBR5JdtZwrxe/jyZjoplGG/fA8Krlh 29AIQTG/BikDOexH/M0IFbg= X-Google-Smtp-Source: APXvYqwI4rPRWvTHNNFqsXc8ac06Ncxqde6pMFjUupKpUYOqV0JMcUlN9gZbrVFLyp/Ato3SlT9+6A== X-Received: by 2002:a0c:a8d2:: with SMTP id h18mr64318697qvc.16.1564064936606; Thu, 25 Jul 2019 07:28:56 -0700 (PDT) Received: from [31.133.129.140] (dhcp-818c.meeting.ietf.org. [31.133.129.140]) by smtp.gmail.com with ESMTPSA id u1sm27684886qth.21.2019.07.25.07.28.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 07:28:55 -0700 (PDT) References: <156357072926.30941.12327072409526858356.idtracker@ietfa.amsl.com> To: Anima WG Cc: "Liubing (Leo)" From: Brian E Carpenter X-Forwarded-Message-Id: <156357072926.30941.12327072409526858356.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 26 Jul 2019 02:28:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <156357072926.30941.12327072409526858356.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: ID Tracker Stream Change Notice: X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 14:29:05 -0000 Hi, Since the Limited Domains draft has been discussed on this list, this is to let you know that we've now submitted it for publication as an Independent Submission RFC. Feedback is of course still very welcome. Regards Brian & Bing -------- Forwarded Message -------- Subject: ID Tracker Stream Change Notice: Resent-Date: Fri, 19 Jul 2019 14:12:09 -0700 (PDT) Resent-From: alias-bounces@ietf.org Resent-To: brian.e.carpenter@gmail.com, leo.liubing@huawei.com Date: Fri, 19 Jul 2019 14:12:09 -0700 From: IETF Secretariat To: draft-carpenter-limited-domains@ietf.org, rfc-ise@rfc-editor.org Stream changed to ISE from None Datatracker URL: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ From nobody Thu Jul 25 07:36:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDEE1201CF for ; Thu, 25 Jul 2019 07:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7pvhEyBM3t2G for ; Thu, 25 Jul 2019 07:36:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C398112016D for ; Thu, 25 Jul 2019 07:36:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3BC9A548342; Thu, 25 Jul 2019 16:36:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B5B9440041; Thu, 25 Jul 2019 16:36:32 +0200 (CEST) Date: Thu, 25 Jul 2019 16:36:32 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6709.1564009422@dooku.sandelman.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 14:36:45 -0000 First of all, there is obviously an ability to filter out packets NOT to encrypt. Otherwise you would have a lot of problems negotiating the encryption keys. To the best of knowledge, what MUST be supported in ethernet chips is such filtering based on ethertype because thats whats being used also in 802.1x, the basic security architecture. See ACP draft section A.10.2 Secondly, i was told (and this is where i have not tried to validate), that MacSec should equally be able to utilize multiple keypairs, probably mapped by VLAN or ethertype. But the question of course is whether you want/can expect that MACsec MIC chips have that feature. So, the most simple solution would be to put all of ACP onto a separate ethertype, run that all in software (including existing encryption) and use MacSEC to HW encrypt all other traffic. If you wanted to then also accelerate encrypted ACP with MACsec itself, you would not actually use the new ethertype to encapsulate the secure channel packets, but just negotiate a separate VLAN for that. In which case you just use IKEv2 from the scure channel protocol (as an example) to negotiate keys but instead of IPsec/ESP you use MACsec/VLAN). CHeers Toerless On Wed, Jul 24, 2019 at 07:03:42PM -0400, Michael Richardson wrote: > > I was asked to decode words mangled at the mic at Tuesday morning's ANIMA > meeting. > The word was "MACsec", and > https://en.wikipedia.org/wiki/IEEE_802.1AE > https://1.ieee802.org/security/802-1ae/ > > provides a reasonable description, and probably the getieee mechanism > might get you a copy for free, but IEEE doesn't have a URL that > leads to the actual document. I did read it once. > (One of the URLs in the wikipedia page leads to 404) > > https://ieeexplore.ieee.org/document/8585421 > might get you the document if you have a valid password, which > I used to, but apparently not anymore. > > Given my newly acquired understanding that MACsec applies on a per-port > basis, not on a per-VLAN basis, this means that it would be rather difficult > to do peer discovery and security for a L2-bridged LAN. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jul 26 16:33:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACFB1201CF for ; Fri, 26 Jul 2019 16:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 spPCU75YGV6m for ; Fri, 26 Jul 2019 16:33:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C558120181 for ; Fri, 26 Jul 2019 16:33:41 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 06ABA1F44B; Fri, 26 Jul 2019 23:33:40 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 045ED1A97; Fri, 26 Jul 2019 19:33:42 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-reply-to: <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Thu, 25 Jul 2019 16:36:32 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 26 Jul 2019 19:33:41 -0400 Message-ID: <27695.1564184021@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 23:33:43 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > First of all, there is obviously an ability to filter out packets > NOT to encrypt. Otherwise you would have a lot of problems negotiating > the encryption keys. To the best of knowledge, what MUST be supported > in ethernet chips is such filtering based on ethertype because thats > whats being used also in 802.1x, the basic security architecture. See > ACP draft section A.10.2 Yes, but the key management packets can be packets that are "special" at the MACsec level. > Secondly, i was told (and this is where i have not tried to validate), > that MacSec should equally be able to utilize multiple keypairs, > probably mapped by VLAN or ethertype. But the question of course is > whether you want/can expect that MACsec MIC chips have that feature. The people in the line behind me did not agree. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl07jdUACgkQlUzhVv38 QpDr+Qf/cJspigItUMOJlAlyPE3JnaAuhOK3G4uwoRwFAazn+oboXBKD9BtLPqBW CE6+ZbM14WUlEeXzq5hGn/B0Jb6yRRtWRhVskT8XP57tSBg4TdCCy0G/EamSjqat MaC8W/E8WERJbROQpZhXB90bnj3hgSC3XHbaR2PQU/DbCukwfbGDcO2WtHk6Ntjs LMV7nrE2NaGMyYh9EvpNm3iwhz2GrBXW0LRZQmA0wk8G4UmSAmnqmF7VxReR8dc5 1k2f/UvxOpng90upATZX4+dIAF4hdhxnioSOJnMVDMqEraHv3wNpuIw7nWPK4+5B g+ZFRjfXOU5OWIpunW8d6+PBmcubqQ== =J5kW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 29 15:09:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2F3120090 for ; Mon, 29 Jul 2019 15:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5_2k5LRjO9Zd for ; Mon, 29 Jul 2019 15:09:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D169112004E for ; Mon, 29 Jul 2019 15:09:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D88EA548002; Tue, 30 Jul 2019 00:09:21 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BDB4F440041; Tue, 30 Jul 2019 00:09:21 +0200 (CEST) Date: Tue, 30 Jul 2019 00:09:21 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20190729220921.j4y5oqtoj4hkfekg@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> <27695.1564184021@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27695.1564184021@dooku.sandelman.ca> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 22:09:28 -0000 On Fri, Jul 26, 2019 at 07:33:41PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > First of all, there is obviously an ability to filter out packets > > NOT to encrypt. Otherwise you would have a lot of problems negotiating > > the encryption keys. To the best of knowledge, what MUST be supported > > in ethernet chips is such filtering based on ethertype because thats > > whats being used also in 802.1x, the basic security architecture. See > > ACP draft section A.10.2 > > Yes, but the key management packets can be packets that are "special" > at the MACsec level. My point was that the "special at MACsec level" propoerty that can expected to be supported by MACsec capacle MIC chips is ethertype and hopefully VLAN tag. But i don't think nothing else. > > Secondly, i was told (and this is where i have not tried to validate), > > that MacSec should equally be able to utilize multiple keypairs, > > probably mapped by VLAN or ethertype. But the question of course is > > whether you want/can expect that MACsec MIC chips have that feature. > > The people in the line behind me did not agree. Hmm... Don't remember if anyone else stated that there can be one one keypair. As i said in the other mail, both a single and a douple keypair solution are possible to build, i just think it would be nicer if ACP can be separately encrypted from data-plane, but as long as ACP is responsible to manage the encryption key, it can equally encrypt both ACP and data-plane. Its just that right now, ACP is not optimized for fast reconvergence, so a data-plane could converge faster and then it might still need to wait for ACP. But thats solely a matter of routing protocol and aliveness parameters of ACP/data-plane. Cheers toerless From nobody Mon Jul 29 17:28:41 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE38120059 for ; Mon, 29 Jul 2019 17:28:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156444652017.28012.11407686155566278331.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2019 17:28:40 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 00:28:40 -0000 Changed milestone "Submit bootstrap a trust infrastructure solution to IESG (Standards Track)", resolved as "Done", added draft-ietf-anima-bootstrapping-keyinfra to milestone. Changed milestone "recharter to refocus scope, or close", set due date to August 2019 from November 2018. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Mon Jul 29 17:34:24 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1B512002E; Mon, 29 Jul 2019 17:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dNdZzEN37-kl; Mon, 29 Jul 2019 17:34:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CC1120019; Mon, 29 Jul 2019 17:34:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A672B3808A; Mon, 29 Jul 2019 20:33:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F2EC4C73; Mon, 29 Jul 2019 20:34:18 -0400 (EDT) From: Michael Richardson to: ivaylo petrov , core@ietf.org, anima@ietf.org In-Reply-To: <9c1398c8-ab50-77e2-9e42-876e91959f0b@sandelman.ca> References: <16149.1564022542@dooku.sandelman.ca> <9c1398c8-ab50-77e2-9e42-876e91959f0b@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [core] SID files and IANA X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 00:34:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ivaylo wrote: >> Given that draft-ietf-anima-constrained-voucher is past WGLC, I {mcr: it's not past WGLC} >> personally don't see any problem to add it to the initial SID range >> allocations (sec 6.3.3) with a new range (as IANA is not responsible >> for the mega range that you have mentioned). That being said, I want >> to be sure that the SID draft will not be delayed in case that draft >> is delayed for any reason, so maybe we will need to discuss. Michael Richardson wrote: > I have opened a github issue against the draft asking for the > allocation to be included. I'd like to get the running code updated > ASAP with the new values, and we'll have to respin our document and > build new sid files. I meant to paste this, but I hit send instead: https://github.com/core-wg/yang-cbor/issues/11 =20=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0/kIoACgkQgItw+93Q 3WXCCwgArfY4ywDESbaCQ61WEfMi7oVZxImRFyxxf9WY2VAOUGzi0dWDTp5Vnibr c2HNMid9o2wtnGQtkspdl8aP/7r8AiAeeyQ3EoXxyFsE1yj+g5KOkQlt8S1BCwDR P6J7Un8a+beMFtQNWnfLFrdghgQfVypd5i98ugH8roWUqLQt86TTrDhGIYucWQn5 55weSrOx7E0bycZ8c2bOS9hZQvxfHVT7PPgHxOIbrAu1Vg4t3jT3FEkIbgSG2jN0 +TARjJbmY7di0SCQTgMyrupmseZTWd2AYq5jQcwVybgvgsTTO+zfqHQRZyPWbZki rjbikjT8Umt2VuMIJg7v8tBS8EAWOA== =xwvR -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 29 17:54:56 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036AE1203D1 for ; Mon, 29 Jul 2019 17:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Yh80f4LSr2w3 for ; Mon, 29 Jul 2019 17:54:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB381203D9 for ; Mon, 29 Jul 2019 17:54:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2514F54806A; Tue, 30 Jul 2019 02:54:44 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0FD50440041; Tue, 30 Jul 2019 02:54:44 +0200 (CEST) Date: Tue, 30 Jul 2019 02:54:44 +0200 From: Toerless Eckert To: anima@ietf.org Cc: ibagdona@gmail.com Message-ID: <20190730005443.rytes74pli6wqg5l@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] anima: updated milestones for WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 00:54:54 -0000 We have updated the milestones for anima on datatracker. Alas, our AD (IGnas has to approve) before they can be seen publically, so i have appended what the system summarized back to me here. This is primarily for adoption after recharter and the submission to IESG are rough estimates from the discussion we had in the WG meeting and hallways. Cheers Toerless & Sheng Changed milestone "Adopt API for GRASP", added draft-ietf-anima-grasp-api to milestone. Changed milestone "Adopt variation of GRASP voucher for constrained Pledges", added draft-ietf-anima-constrained-voucher to milestone. Changed milestone "Submit bootstrap a trust infrastructure solution to IESG (Standards Track)", resolved as "Done", added draft-ietf-anima-bootstrapping-keyinfra to milestone. Changed milestone "recharter to refocus scope, or close", set due date to August 2019 from November 2018. Added milestone "Adoption of draft for ASA lifecycle management (Informational)" for review, due September 2019. Added milestone "Adopt a draft for constrained BRSKI join proxy (Standards Track)" for review, due September 2019. Added milestone "Adopt a draft for information distribution via GRASP (Standards Track)" for review, due October 2019. Changed milestone "Submit variation of GRASP voucher for constrained Pledges to IESG (Standards Track)", set due date to November 2019 from April 2019, added draft-ietf-anima-constrained-voucher to milestone. Changed milestone "Submit API for GRASP to IETSG (Informational)", set due date to March 2020 from April 2019, added draft-ietf-anima-grasp-api to milestone. Added milestone "Submit a draft for constrained BRSKI join proxy to IESG (Standard Track)" for review, due May 2020. Added milestone "Submit a draft for ASA lifecycle management to IESG (Informational)" for review, due December 2020. Added milestone "Submit a draft for information distribution via GRASP to IESG (Standards Track)" for review, due February 2021. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Mon Jul 29 18:14:25 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2187D12002E for ; Mon, 29 Jul 2019 18:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ObW5fzsFgH4Z for ; Mon, 29 Jul 2019 18:14:21 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32241120019 for ; Mon, 29 Jul 2019 18:14:21 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id az7so28167444plb.5 for ; Mon, 29 Jul 2019 18:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EgIUrYarSW2Hpoeap1no7Tk6CPzUviqdHR5SuRHRhxo=; b=fxxneR7u/Pbh2QxFZGnKJvwsa5kanQIkBY9HIqPTa27QvQcbklevZMey3ZzLrj2dXl EDxcutRnucC1ouq6YKQaoA8eF6vEbPmeD8q0s3M3iZwMZcmhw3GxYy1h9CbS/5i2/Ror YvKhdxzSjQ8+6LycB5ydocu1cIceDiUt0orSTmAdJIs7yetg0p4k4b9n9fzm72AEk9kI txJXiP0veVIaeCLpmmzgouXVspljwfVgwrxC7yQknZx/Aj+Fr8rg5Ds3zRf5JWHMdPg1 YZH2pSlMfHSI96s59Mg2A3IXKyeg2QVrG0jIJx67mW9u2ldXqTafYCdsyhDWzgFm1Vcj bnyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EgIUrYarSW2Hpoeap1no7Tk6CPzUviqdHR5SuRHRhxo=; b=G5UN6OSi/A/i6zCrkzFVJTeEbZCspfNsc6y8N4TOIHyqSlkvNnuHu/4hP7f7mn+EKS ciWxtG+jXp7ST3bwsWpq6O1fPSfmJKhOV8cij6UKT2E70gnfcYh2+mqh0fUbVhp9+h15 LTM75uxTsq2kjVtFtuFwImsg7iD/KvtbPxR+yWCcGvEm4uy9EnVFBK087jTTXJRl/qXG Y6wYtXY0CiEJlrVYNogOuFdFuGBGlQlP6QGKoEQYO39ZDCncrLQrmpiPTnBhNmCgxUk+ y3P/woiBF8inbxxL4fdlcnl0z4+AsPzRRKbXXhemLBIFlS72FpVeUr3tDnzQgmb8sVTc S81g== X-Gm-Message-State: APjAAAUoqwejGST7kvrlWx/V4BDPTXZn0B7Z6sMWCBRkS/wjxuJsCpoT PdvfrZsBt5KY5B6LQj6DudE= X-Google-Smtp-Source: APXvYqyyhubo9Khxm9g1tks80rap28RjReAq0GQADH6sC67ij00TXvMuE9LliwL1GVxod8EZt+gAKg== X-Received: by 2002:a17:902:9688:: with SMTP id n8mr110342529plp.227.1564449260759; Mon, 29 Jul 2019 18:14:20 -0700 (PDT) Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id a3sm66602725pfl.145.2019.07.29.18.14.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 18:14:20 -0700 (PDT) To: Toerless Eckert , anima@ietf.org Cc: ibagdona@gmail.com References: <20190730005443.rytes74pli6wqg5l@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <755a97a7-c937-5479-178d-0f8c801d95c9@gmail.com> Date: Tue, 30 Jul 2019 13:14:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190730005443.rytes74pli6wqg5l@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] anima: updated milestones for WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 01:14:23 -0000 Hi Toerless, "Adoption of draft for ASA lifecycle management (Informational)" Are you referring to draft-carpenter-anima-asa-guidelines there, because its scope is wider than just lifecycle? And back in history we also had draft-ciavaglia-anima-coordination (ASA coordination) and draft-peloso-anima-autonomic-function (lifecycle). Regards Brian On 30-Jul-19 12:54, Toerless Eckert wrote: > We have updated the milestones for anima on datatracker. > Alas, our AD (IGnas has to approve) before they can be seen > publically, so i have appended what the system summarized back to me > here. This is primarily for adoption after recharter and the > submission to IESG are rough estimates from the discussion we > had in the WG meeting and hallways. > > Cheers > Toerless & Sheng > > > Changed milestone "Adopt API for GRASP", added draft-ietf-anima-grasp-api to > milestone. > > Changed milestone "Adopt variation of GRASP voucher for constrained Pledges", > added draft-ietf-anima-constrained-voucher to milestone. > > Changed milestone "Submit bootstrap a trust infrastructure solution to IESG > (Standards Track)", resolved as "Done", added > draft-ietf-anima-bootstrapping-keyinfra to milestone. > > Changed milestone "recharter to refocus scope, or close", set due date to > August 2019 from November 2018. > > Added milestone "Adoption of draft for ASA lifecycle management > (Informational)" for review, due September 2019. > > Added milestone "Adopt a draft for constrained BRSKI join proxy (Standards > Track)" for review, due September 2019. > > Added milestone "Adopt a draft for information distribution via GRASP > (Standards Track)" for review, due October 2019. > > Changed milestone "Submit variation of GRASP voucher for constrained Pledges > to IESG (Standards Track)", set due date to November 2019 from April 2019, > added draft-ietf-anima-constrained-voucher to milestone. > > Changed milestone "Submit API for GRASP to IETSG (Informational)", set due > date to March 2020 from April 2019, added draft-ietf-anima-grasp-api to > milestone. > > Added milestone "Submit a draft for constrained BRSKI join proxy to IESG > (Standard Track)" for review, due May 2020. > > Added milestone "Submit a draft for ASA lifecycle management to IESG > (Informational)" for review, due December 2020. > > Added milestone "Submit a draft for information distribution via GRASP to > IESG (Standards Track)" for review, due February 2021. > > URL: https://datatracker.ietf.org/wg/anima/about/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Jul 29 18:22:35 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180C2120058 for ; Mon, 29 Jul 2019 18:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZS4z0-_V3xyd for ; Mon, 29 Jul 2019 18:22:32 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3CF12002E for ; Mon, 29 Jul 2019 18:22:31 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C1B3A548002; Tue, 30 Jul 2019 03:22:26 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A46F2440041; Tue, 30 Jul 2019 03:22:26 +0200 (CEST) Date: Tue, 30 Jul 2019 03:22:26 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org, ibagdona@gmail.com Message-ID: <20190730012226.t54nz7cthnbms3a6@faui48f.informatik.uni-erlangen.de> References: <20190730005443.rytes74pli6wqg5l@faui48f.informatik.uni-erlangen.de> <755a97a7-c937-5479-178d-0f8c801d95c9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755a97a7-c937-5479-178d-0f8c801d95c9@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] anima: updated milestones for WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 01:22:34 -0000 Yes. The datatracker entries, actually say this is draft-carpenter-anima-asa-guidelines, somehow that level of detail did not get copied into that appended mail (generated by datatracker), but it will be visible once the milestones are acknowledged by Ignas. We've been using "Lifecycle and Management" in the Charter, and the milestone already said "lifecycle" too. I am hopeful IAB will not get confused beteween lifecycle, management (charter, milestones) and guidelines (in the title). Cheers Toerless On T-e, Jul 30, 2019 at 01:14:20PM +1200, Brian E Carpenter wrote: > Hi Toerless, > > "Adoption of draft for ASA lifecycle management (Informational)" > > Are you referring to draft-carpenter-anima-asa-guidelines there, because its scope is wider than just lifecycle? And back in history we also had draft-ciavaglia-anima-coordination (ASA coordination) and draft-peloso-anima-autonomic-function (lifecycle). > > Regards > Brian > > On 30-Jul-19 12:54, Toerless Eckert wrote: > > We have updated the milestones for anima on datatracker. > > Alas, our AD (IGnas has to approve) before they can be seen > > publically, so i have appended what the system summarized back to me > > here. This is primarily for adoption after recharter and the > > submission to IESG are rough estimates from the discussion we > > had in the WG meeting and hallways. > > > > Cheers > > Toerless & Sheng > > > > > > Changed milestone "Adopt API for GRASP", added draft-ietf-anima-grasp-api to > > milestone. > > > > Changed milestone "Adopt variation of GRASP voucher for constrained Pledges", > > added draft-ietf-anima-constrained-voucher to milestone. > > > > Changed milestone "Submit bootstrap a trust infrastructure solution to IESG > > (Standards Track)", resolved as "Done", added > > draft-ietf-anima-bootstrapping-keyinfra to milestone. > > > > Changed milestone "recharter to refocus scope, or close", set due date to > > August 2019 from November 2018. > > > > Added milestone "Adoption of draft for ASA lifecycle management > > (Informational)" for review, due September 2019. > > > > Added milestone "Adopt a draft for constrained BRSKI join proxy (Standards > > Track)" for review, due September 2019. > > > > Added milestone "Adopt a draft for information distribution via GRASP > > (Standards Track)" for review, due October 2019. > > > > Changed milestone "Submit variation of GRASP voucher for constrained Pledges > > to IESG (Standards Track)", set due date to November 2019 from April 2019, > > added draft-ietf-anima-constrained-voucher to milestone. > > > > Changed milestone "Submit API for GRASP to IETSG (Informational)", set due > > date to March 2020 from April 2019, added draft-ietf-anima-grasp-api to > > milestone. > > > > Added milestone "Submit a draft for constrained BRSKI join proxy to IESG > > (Standard Track)" for review, due May 2020. > > > > Added milestone "Submit a draft for ASA lifecycle management to IESG > > (Informational)" for review, due December 2020. > > > > Added milestone "Submit a draft for information distribution via GRASP to > > IESG (Standards Track)" for review, due February 2021. > > > > URL: https://datatracker.ietf.org/wg/anima/about/ > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 29 19:46:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F9112002E for ; Mon, 29 Jul 2019 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xl2ZNtI5oHAZ for ; Mon, 29 Jul 2019 19:46:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E552D120019 for ; Mon, 29 Jul 2019 19:46:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 908EB3808A; Mon, 29 Jul 2019 22:46:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 14453BDF; Mon, 29 Jul 2019 22:46:33 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-Reply-To: <20190729220921.j4y5oqtoj4hkfekg@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> <27695.1564184021@dooku.sandelman.ca> <20190729220921.j4y5oqtoj4hkfekg@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 02:46:36 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: >> The people in the line behind me did not agree. > Hmm... Don't remember if anyone else stated that there can be one one > keypair. As i said in the other mail, both a single and a douple > keypair solution are possible to build, i just think it would be nicer It's not about keypair, it's about what IPsec would call the SPD, which is a way to select which traffic goes into which tunnel. I would also have expected it to be able to select based upon VLAN tag and destination ethern= et type, but people said that wasn't so. I would love to be told I'm wrong. I can see if one was building the minimum viable solution that can deal with state-level attackers on point to point fiber runs, that just encrypting everything works well.=20=20 > if ACP can be separately encrypted from data-plane, but as long as ACP > is responsible to manage the encryption key, it can equally encrypt > both ACP and data-plane. Its just that right now, ACP is not optimized > for fast reconvergence, so a data-plane could converge faster and then > it might still need to wait for ACP. But thats solely a matter of > routing protocol and aliveness parameters of ACP/data-plane. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0/r4gACgkQgItw+93Q 3WWviQgAubn6oA/oBL34thkY51gq/3TBCRuME2oYJ7gxXNUPRfeU7qeHtoArl13q 7QCvyv1TedIWRZQ7YXX/oAks/1vU6hoT9WXttlllmDNnh7l4COntf5E/g/lkW2hO /7TasuUIoKXUweYxYYAZ8bWiRFnPk2RX4Hb6bheROzvyJ1mqh6h0IRJRLxvr1gsh nc1UAqRxAi79FGusKdumbkuGgbHQbmxehRvHCTNEi0fFYeINS84fyxRi0hGPCQh5 keOV7m4aWR8jZM5BQr5zZnbzQ2HNYiN96fpfGV+UHpJXjgDpmFB1w520XfBX8jYJ fLPh1bDOGWUNINm+tla5hUJ2OoJe1g== =+VtS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 30 00:51:09 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5F120182 for ; Tue, 23 Jul 2019 02:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Skk5Xfrf5Yzw for ; Tue, 23 Jul 2019 02:27:00 -0700 (PDT) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CC0120177 for ; Tue, 23 Jul 2019 02:27:00 -0700 (PDT) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 02:26:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,298,1559545200"; d="jpg'145?scan'145,208,217,145";a="180682104" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 23 Jul 2019 02:26:59 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 23 Jul 2019 02:26:58 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 23 Jul 2019 02:26:57 -0700 Received: from hasmsx107.ger.corp.intel.com (10.184.198.27) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 23 Jul 2019 02:26:57 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.134]) by hasmsx107.ger.corp.intel.com ([169.254.2.129]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 12:26:54 +0300 From: "Mendelson, Tsippy" To: "tte+ietf@cs.fau.de" , "anima@ietf.org" CC: "Ruan, Xiaoyu" , "Jayanna, Prabhu" , "kwatsen@juniper.net" , "Michael.H.Behringer@gmail.com" , "mcr+ietf@sandelman.ca" Thread-Topic: Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 Thread-Index: AdUvGpUo2g/H2b+cQWiZ9uaJTHYs9ASHR2sA Date: Tue, 23 Jul 2019 09:26:54 +0000 Message-ID: <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> In-Reply-To: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTVmYzE2MzktM2U1Yy00ZjJhLWJiZGYtZmQ1OTBlNzVhZWNlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSUZ1WmV2QlI1S1UxemZ2T01ybTB1aFJHMmhHUVpzc1BHV04wK0lzQkl0NE5pbDRiSWRJR1FPam9MK05rb0czbiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.184.70.10] Content-Type: multipart/related; boundary="_004_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 30 Jul 2019 00:51:07 -0700 Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 09:27:03 -0000 --_004_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_ Content-Type: multipart/alternative; boundary="_000_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_" --_000_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Sending again to wider ANIMA audience - as I received no response. Thanks, Tsippy From: Mendelson, Tsippy Sent: Sunday, June 30, 2019 11:18 To: tte+ietf@cs.fau.de Cc: Ruan, Xiaoyu ; Jayanna, Prabhu ; Mendelson, Tsippy Subject: Clarification reg old reference in the BRSKI draft to IEEE 802_1AR= -2009 Hello, We have identified a reference to an old spec in BRSKI draft draft-ietf-ani= ma-bootstrapping-keyinfra-22. The draft refers to: [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, . However there is a later spec: https://standards.ieee.org/standard/802_1AR-= 2018.html The specific quote from 802.1AR-2009 that we would like to ask about is in = section 2.3.1 "Identification of the Pledge": The following fields are defined in [IDevID] and [RFC5280]: o The subject field's DN encoding MUST include the "serialNumber" attribute with the device's unique serial number. (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes) In 802_1AR-2018 we could not find that the "serialNumber" attribute MUST be= included rather we found SHOULD: [cid:image002.jpg@01D54150.D86DC7C0] Here it says: An IDevID certificate subject field shall be non-null and sho= uld include a unique device serial number. We would be happy for a clarification. Thanks, Tsippy Tsippy Mendelson, Manageability Chief Architect, IP Technologies Group, SecIP - CSE FW Architect Intel Israel Design Center Phone: +972-2-589-2468 Cellular: +972-54-7885061 --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Sending again to wider= ANIMA audience – as I received no response.

 

Thanks,

Tsippy

 

 

 

 

From: Men= delson, Tsippy
Sent: Sunday, June 30, 2019 11:18
To: tte+ietf@cs.fau.de
Cc: Ruan, Xiaoyu <xiaoyu.ruan@intel.com>; Jayanna, Prabhu <= prabhu.jayanna@intel.com>; Mendelson, Tsippy <tsippy.mendelson@intel.= com>
Subject: Clarification reg old reference in the BRSKI draft to IEEE = 802_1AR-2009

 

Hello,

 

We have identified a reference to an old spec in BRS= KI draft draft-ietf-anima-bootstrapping-keyinfra-22.

 

The draft refers to:

 

2009.html>.

However there is a later spec: https://standards.ieee.org/standard/802_1AR-2018.html

 

The specific quote from 802.1AR-2009 = that we would like to ask about is in section 2.3.1 “Identific= ation of the Pledge”:

 

=
=
=
MUST include the "serialNumb=
er"
=
=
=
 


In 802_1AR-2018 we could not find that the “se=
rialNumber” attribute
MUST be inclu=
ded rather we found
SHOULD:<=
/o:p>




Here it says: An IDevID certificate subject field sh=
all be non-null and
should<=
/u> include a unique device serial number.


 


We would be happy for a clarification.


 


Thanks,


Tsippy


 


 


 


 


 


 


Tsippy Mendelson,<=
/p>


Manageability Chief Architect,



IP Technologies Group, SecIP - CSE FW Architect


Intel Israel Design Center=



Phone: +972-2-589-2468=




Cellular: +972-54-7885061=



 


 


 


 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_-- --_004_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=74601; creation-date="Tue, 23 Jul 2019 09:26:54 GMT"; modification-date="Tue, 23 Jul 2019 09:26:54 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAkACQAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAHjA0oDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAKGs3ktho17e28JmmggaR Ix/EQCQK8q0vxt4nWXQ9Qm1+01JdWuPKl0uOFQ9upOM5Hzce/wCtemeKP7QHhnUv7Lz9t+zt5O3r ux29/T3rxOzfSWtfD8fhqG7Txat0PtbFHz337ieCM/pnNEfiB/Ce8alex6dpl1fSglLaJpGA7hRn +leXaR4p8Ya01pqlrr2lbrmfK6G5RXMWSM7j82eP6+1dlqOr2viIa74UtVlF9DaFXLLhMsvGDn3F eQINLHg628P22lSx+Lor4DIgIlBDHnfjpjAxntmhbjex9CvKscRkkYIqjcxJ4AHXNcpF8T/Cst2l ut9IqyyeWk7QOImb0DYx+PSt67j36HLHdQyXObYrLHF96T5eQOep7c14WmpnSLeGPw5rV1cn7RtX QdQst7odx9iB+GDzQvisL7Nz3BvEWmr4gTQDO39oPD5yxhDjb67sYrI1vxdbPo3iGPR7tl1HSICZ Mxn923OOowehrl9e1KPw/wDFnTNa1ndbWkunbDIqMyq/ORwD3/nWPpl0NQj+It4kciJcRB4xIhVi p3YyD7YpdPv/AAH1+46nwx8T9FfSdNg1jVD/AGhPGBLKYiEDnsWAwD+grYl1WcfEe300a0oge08z +z/IyWPPz78fpmvMLjXNMvvhRYeF7eymOsSMnlwCBgSd2fMBxggj3710ctpcr8UrCyL/AOlDQDFv z/HtIzn61T3/AK7CW39dzqpPiZ4Ti1Q6e2pfOsnltL5beUH9N2Mfj0rR8QeL9F8Mxwvqd1taf/VR xqXd/cAdvevErGSO38LXHhvU9Wvbe4NyVfSodNWSRzuyGDnBP5g9ulddqZXwl480HWNaWd9Mj05b cXDxFjE4GPmAzg/TPWl21Dqzf134naTb+EJ9Z0adbmcOIY43RhtkPZhwRxk++K6Dwjr0PiTw9bah FJ5jlQsx2Ff3gHzcH3rgNd1Sx8SeAvFF3o2gm1g8xD9qEe03mHBLYwDx1/Gu48C6rZ6t4SsZLKQu sMSwyZQrh1AyOaF1E+h0lFFFAwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAqMQxq5dY0DHqwHJqSigBMDOcDNM8qPzPM2Lvxj djmpKKACovJiEhk8tA+OW28/nUtFAEbxpJjeitg5GRnBp+1f7o59qWigCPyk3B9i7gMA45FcjpPg i4s/Gdx4m1DWXv53Vo4IzFsESk9Opzgcdq7Gil1DoM8mPzBJ5aFwPvbefzpXRJFKuoZT1BGRT6KY DQihdoUBcYxikSNI1CxqFUdABgU+igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigBpNYz+JLRPFcfh8qwmkgMqyZ+XII+T64OfpWlfXtvp1lNeXUgj hhQszHoAK4DXLPUIvDkXiZbq1aa0uBqKhUIYg8FN27BG3jpzgUuuuwW08z0em703bNw3Y6Z5qtpu oW2q6fDfWkgkhmQOpHvXEaDc6TfOltqu8eIbXUXdkGVlLbjg+6bSPbApivoegeYm7ZuG7H3c81Bd 31rZW0tzcTpHFEpZ2LdAOtee6SdM1K9SHVL+6h1601FnaCNFWRjuOOduTGVIzzjFVYtK0q98NeLb lbWG4ube5uvJI+YxgjjaOw4yKV/yKS1t52PRjdTyy2jWscUlrMpaSRpMMoxldq45z36YrKm13UJ7 m8h0awgu/sMwhmEs/lksVBJHBGBkZ9eaw45dM/tzwbJZtbqrRzAGPADfux6e+fxqvaRaR9l8blI7 YFZJNpUAEDyl6e279actPuEtl5nfwSubSKS68uOUqC4V8qrY5APcVM0iIAWdVB6ZPWvOLfUrCGTQ U1x0/smfR1SKSUZi87+IE9AduMfjT9XfSIfs2mxKyKNKl+zPfFmDKTgKinkucA56gY4NJgjvJdQt Yb6CxkmUXFwrNGmeSF6n9RVjem8JuG7rtzzXm+myWM+oeDLy68mTfp8kXmyrndKAuBk/xA596NAO malc2a31/dxeILO7YywIirIWyc7jtyYyOeuMYpiR22lapc3txqEN5Y/ZPsk2xG80Osi4yDkdD6jt Wmrq4yrBh6g1jeKo4m8PXMbXgsVdlxOUDKrbgRuHcE4B9iap+DJpWj1GG4s7aGeG4AkltDmCc7Rh l9OMZHrRuPY6fIHJOBRkcc9a5zxR9kkmsbe4u7WJmLukV4pMM2AMg8gZGQRn34qhH9mPhRpUjWOO 2v1cOkpeNf3oyyMcfLgkegGRQtQOnv7z7FYz3RieYQoXKRkbiB1xkgdPepoZVmjSRTwyhsdxmuRu 9U0k3uvta3kJVtNDSMr/AClsuMg9CeQOPam6Z/ZKxaS+kz79Rdl83D/vXXB3+aOuB79DjFAbHVvd Muow2ogdkkRmMq/dQjHB+uePpVosBjJAz0zXO3ul2NjrumXNrbpDNNcsJGXq42Mefx5rB1hPO8Ra imqSaWqrtNqb+Z0KR7Rlozxg7s5I5pXHY9AyByTgVDdXUNpavczyBIo13M3XArly0b2ujJrV5Fc2 TQNvmYkQzScbd2euRnGetF7p2jXHhfWI7Am6tjufZktGjBekZ6YHoMgfpTYlqdajrIoZWBBGRihm CjLEADqTWLoDaDFH9n0iS18xo1eRIHBPTqaq+Nbq1trCxF4oMcl7God32xRnkgyf7Pt3OKGCOj8y MqG3rg9DmlV1blWDD2NeRzTWj6Bf28k0beV4iTYFBQKpcHKjOQCOevSrWsSppl/4lg0kCO1Bs5J4 rftGT+9YAeo64oWodbHcxa08viuTRvJjMaWguFmWTJOWIwRjjp61s1w2kXGjP8Rnk0eS3MU+lJgw EbWIc+nfGK6LxLJAmiTLc3RtY5CqebgkKdw64xx2PI4Jo6B1Zr7gRkEEfWkzj/D1rktGgtHudStI obOQPajcbByYW64Gzor9+pzxUNrqelvN4dUXkbXakxsA2WUbT8renPY0AdTp9+uoQNIIngZZXjZJ Su4MpwehIpb65NnbmVYHuGDKvlx/e5IBP4Zz9BXF28ugzW+sXDXSvfi8nNs3mfODn5PK+p9Ovet3 XtKtLrQZr28tVa9itciQ/eVgP8aAOhJA5JAHrR71xXiTz5LzSo7r7IdOeA5F8xELS4GA2OCcdAfe ksmeLw7cql/DLYLdhX+xyM628X8ShjzgH04AJoWoHbhgRkEEVBaXlvewCa3kEiEkA/TrWLp1r4dO qMNLkiJkgKSwWzZiK/3mA4BPr1NZ/hSLw7pkMSK1rBqHmSRbC4EmQxyMZ9KAN0a9ZHWv7JPnJdFS y7omCsPZsYNP1DUzYS26taTSxzuIzKhXahPTOSD+QNcpc6jLdrqGuWsmnva210hWdrg7kEfBGNuO QTgZ71ra/ruk/Y7B21G2QSzxSqGkUZT1+lC6AzduruGzWNrhwgkcIpPdj0FQ6nqlppFkb27ZxApA dkQttycZOO3vWP4qi03U9Is7ybybi1juUfzcgoFJwTn06c0zVLnQoPDF1FY3FoLaOVFkCSAoGLqS CenTtSuJbm3/AGtbf2jFYjzTLNH5iMIyUI/3ulXgQTwRkdea5O2uDZa4lqA00dvayz27IM+ZEeQA e5HSsy2v7SDWdMuRc6ZA13K3mRwZMm1h0kfODz6jrwKY+p3+5fUfnQWVepA+przi3s9Jlt4ZI2WQ ypdk/vSwdl5UdeSvUDt2p16/2/UkbUJdMmtWs4mszqErBG+X52Ujjdnv1FAHoprF1TWZbXUoNMso Y5b24ieVBK+1QF7EjPJJp/hnzf7BtRJeJeEA4mjJYOM8fMeW9M96wtUj01vilpazR25lNlKWDqMl sjb+PpQ1rYV9DpNJuNQubV5NTtIbSUNxHHN5mB7nA5qv4j1l9F0KbVLeGO5ERXKmTaMEgcHB9elc M14lppWsPDI32KLXybwQgMVhPU4weM+oqfV49Hg8G6/daTqMlzbXTxMSdohD7lyEwBz64oXQb00O +vbxrbTZLpURnWEyLG77dxAzjP8A9aoNC1b+1tCstRkVYGuohJ5e77ue1chfXtjJr2r2+uNF5cmm odN87Gx1KHdsz1bd+NZNvKB4Z0u6tZrO98jTFW40264MiBs7o27PntQtwPWabvTfs3jd6Z5qK1fz LCB0Rk3RKVR+o46GuE8N3Ok34totQ3/8JHZ3kjOnIlL5PLeqEY9qXcD0Dem7ZuG70zzQZIx1dQc4 5avL9zXXhVskr4nh1LtxPv8AM/PaU/DFN1S30yVPHMkiwPLCY3iOfuPs6r6HPcUwPUvMQkgMpI6j PShZEZiodSw6gGvNZo9Pi1q0W2MWb3QJmuNp5nbaCC3qevXmodEsLFovCF7pTA3rD/TXRyS8Gw7/ ADOemcYz3pAek3U0i28ptRFLOqExo8m0E+57U+GVvIia42RyMoLKGyAcc4PevM9K0/R3+HmtX/lw NcRm7jExOSqljhR6DpU+py/8S7T7y3ms7sxaVH52nXRwJY8DJibs+aoD0kyIpAZ1Bbpk9adXmFxL pmo6jqFjr93dWE8hhexQKPM8vaCojJU4YNkHFekKfLs1J8xisfO775wO/vUt2Vw62JBIjMVDqWHU A04kDqcCvLtI1CxPiDw7c20scKSzXMTpy0oJz8srd2J6DHHvXb+MLc3PhDVYli81jbOVXGeQO1N7 XDrY2tyjuPzpBIjHAdSfQGvMzqOl3eraPJHcRTIdBljkbOQSFHyntnrx1qPQV0+1/wCEIuYTElxc JJHM4b5pBsPDHuM+tC1Fc9HsprqRZjdxRR7ZCE8uTcCnYnjg1ZWSNhlXUjvg15bFfw2WjXLK3/Es TxG4vfLyQsJI6/7JP4U/UUsLweMv7Kjikt2sIHj8hQVLAE5XFC1Gz1HIzjIzTRIjEqrAkdQD0rzi TUYbrxBHNotxHNcv4fdYmjOd8gK4APdgM+4q34R/sPUL/T7+x1C5e/itjFcW6qF28fN5oCg5DZwT 3oWoPQ70sqjLEAepNAdWxhgc9Oetc/4vj87TbeNL6KymNyhhadN0TuOQjj0PrXKfa4kTw9qF1Zwa ctrq8kc7xtmEEqcsrdkJ/WhagzsvEetTaJZwXMNulwJbmOBgZMbdxxkcc/pWlNJIttI9r5csqqdo Z8KW9CecV5fcyWk+i64kTgW41+KRtowEjJXLew9605dNsorrxIdJjT+yJdLzKsZ/dG455Xtnb1x7 ULa47a2O+hmb7LFJdeXFIVG8B8qrY5APcVKzqgyzBR6k15rJd2kR0SDXrprfTbjRo1hleNTH5mBu BJBAJHSpVm0vSdR02y1ieZ9EbTmSznvhkGTdzk44bb09qBI7x9QtU1GPTzMv2mWMyKmedo7/AK1Z JA5JwPeuCtrXSbLxtogWHZC2muls1wuXZg428nknHTvit7x15Z8Eat52Av2Zsbj0Pb8c0ugdTfDq xIVlJHUA9KRZEbO11O3rg9K85ifTtM1yzktVws+gO0625/eTEBSOe7dcE1X0a707+27Vo5rUW1zo bgpHkrkEHa7fxuBnJ/ShjseneZHnG9c9cZpQ6Mu9WBX1B4ryjTLbShpPgqciMTTztFNJv+Z4yHyr HuucDBp5uoNOj1CGF/K0i213/SUgXcsMRQc7f7u/tj1pvQlO56orK43KwYHuDVWa/t4L+GyaVRcT qzRxk8kDqfp2rG8JW+lwx3kuj3s13azz+ZuOPKVyOQmABjpntmqWvpZRfELQLi8jiCtDOokkXq3G 0Z9euKT00H5mz4e1t9btJpp4UtpIruW38sSbs7DjOeK1vMTfs3rv/u55rylP7PTRTqKNCLxPEfyT 7vmVTKMgH0xnpU15qVg2rW9zBIkDw6+FmEhLTY6Es38KEYwKb8gPSLbULW8muYbeZXa1fy5cH7rY zikvZbuJYjbRRSEygSeZJs2pnkjjk+1c14SjsbfxL4khSKKO6+27toUB9hRefYE/rUnjtreNNFkm KKy6tAVLfXn9KXQN3Y1/EervoeiXWoRQpO9um/ynk2bh7HBq/DcLJbQyuwTzUVgCfUV5nrd3ZTaX 4ut9ZMQ1RZGa3WX7xhwPLMee3Xp3zVi+udLutUuLHxBfPaW1zYw/YJAqlWXbhtjEHDBsdPamhHpD Oi/edVx6tVeTUbVNQisGmX7RMhdEzztGMn9RXBTWWkyeKL63vAJ1TQYyRdEbiwJ+Zx/fxjNQ6A1l JqvhO7vfKkaXSmjWSQbi8ilcDPcj86BvY7W71eXStGv9S1GCNFtmYosUm7eg+79CfSmWd9rkuorD dafaJZkbvtCXJJPHAC47HrzXD3BsG+HXiVGaFlj1OfygcHadwxtrcvfsMPjLw19i8iPfa3AQRYAP yjHTtnP40IGraHah1Lbdw3Y+7nmhXRmKhgSOwNeceHW0vUZbB7q+u49fs5n8+2jVVkLc79525KY5 5PpVrwtI1vr9tb/6NqUE8ErW+oQfLKi7slZh65wM+tAjtr7ULXTYBPdyrEjOsaknqzHAH51n22tv L4lvtImhSKO1hjlWbzM7wxIxjHHSsz4iRQP4chkuY0aOG9gZ3dchF3jJ+nr7VianFo1/4g19ZRby wx6PGYlJG1cb8EDoCOPzoW7G1sejM6ouXYKPUmnCvLxqFnMujpr948WnXWjxrFM6hozNj94CSCA2 Me9d54ft4bXQ7O3t5rmaGNMRyXP+sZexP4fpQK5q0UlLQMKKKKACiiigAooooAQgHgjIowMYwMel RTzxW0LzTSKkUalndjgKB1JrHk8X6NELgz3MkRtYhNKjwOrGM8bwMZK+46d6AN0AAYAwKb5abzJs XfjBbHNY8HirSrh5ooZJnlht/tGzyXBkj/vJkfMO3FZ8Pii01TSNJvjc3Om/bLhBGogP7wnohJBG CO/twaAOn8qPf5mxd+Mbsc4p4VR0AGfaubXxnp63Grrcx3EMGlOFllNvIw6Ak8A4HP5c1rLq1m72 kayOzXqF4MRt8ygAkk446jrigC7tUY+UcdOKNq8/KOevFUtX1KHRtJudSuM+VbRlyB1PoB7k4H41 Ui1VbGztH1OVjdXvKQxoWOcbiqgDOAO5oA1mijdQrIrAHIBXNOKKSCyqSOnFU9N1G21WyjvLOUyQ Pna2COQcHIPIOcio9Q1W2sW+zyyyCeRCyLDGZHAHVsAHgZ70noC1L+xePlXjpx0pBGgcyBFDkYLY 5Nct4U8QGbwjY3mpXUlxc3LSbSseXkwx6KB2GO3FaMXivRrj7D5N4zfb3aOAiF8M65ypOMKRg8HH Sqe9g6G0VDDDAEe9IiJGoVVCqOgAwKxNZ1qxjs51k1C4sTBOkUk0cJO1iQQucEYOQM9Oan1HxBpu meYLu4ZfKVWlZYy4iB4BcgHGff60gNOWJJkKSIrqeoYZFKEQJ5YUBMY244xWVfeJdK04k3NyRGpU SSKhZI92Nu5gMDOR19RWsCCARyD0oAasUaKFRFVQMABcChYo1dnWNQzdSBya59PEWl2UerXlzqk8 kFtciOUPCQLZiANowM45HJ9etX9O17T9Su57W1kk8+BVZ0kiZCVbowyBlTg8ijcBiaTcNqUd5eag 9wsBJhiEaqqE8ZPcnHv3rSkgimx5sSPsOV3LnB9qy/Fd1dWHhnUL2znMM9vA0qMADyB3BB4rGu7r XtP8Jxa/b6kb547dbie1uI0CyLgFgpUAggZIzmlf8B2OveNJEKOisp7EZFKqKqhVUKo6AViHxdpK aZBfySuIpYFnbbGz+WhGctgHA+tWbfXtMutR/s+G4Mlx5AuAAjYaM9GDYwR9DTF0NCOGKIERxogJ ydoxzT2VWGGUEehFchreuXT3vh+TS76WK11C7MMmYQNy4JyNwyOlLFcapeeOdT0n+2J4bW2tYpY1 jjjyGbOeSpyOKAOuCJ/cA/CjavPyjP0rmdD1u+/4SO/8O6s0clzbRrNDcRrtE0R9Vzww79q3ry9t 7CDzrmTYuQq8ZLE9AAOp9hQBMkMcf3I0X6LinEAjBGQayofEemT288yzsPs83kyxtGwdZOy7cZye vSoH8Y6HHaPcyXTRpFOLeUNE26OQ9AwxkUAbUUUcK7Y0VF9FGKRIY0JKxopY5JC4ya55PGdjPrNp p9vDduLiORvMa2kXG0gYwRnr36dKqX3iZNO8IXmqWN9cag4uGiSWSA/I28KQQAOFzwT1pAdaYYi4 YxoWXocciszUtLudScxHUZILRhiWFIxlx3+Y9j3xWZps+zxBBBLr17MbmFpYbKe32cDG4ltoPB6Z rTi8SaXLeQ2i3LB7gt5LsjBJdv3grYwcfWmBpNDE8IiaNWjxjawyMU5I0jQIiqqgYAArJtfE2l3t wkME8jPLG0kP7pgJVU/MVOPm/Cq2keLbPVNIOosk0CGdo0R423MckAAY5PHQZxQBvRxRwjEaKg77 RikEMIlMoiQSHq23n86y4PEulXEe6G4d384wGERt5gcclSuM5xzV+yvIb+0jubdmaOQZUspU/keR QBY2rjG0Y+lBRD1UflTJZY4InmlYJGilnYnAAAySayY/FWkzbys8i7Lc3OGhcF4v7y8cj6UAbBRW XaVBUjBGOKakUcaeWkaqg/hC4FZOn+KtI1K5gt7WeRnuYjLAWiZVkUddrEYJHpmsjxB4lH2jSY9L vJgJtRSGQrEfLlXncu8jtjsaLapB5nY4HHAqNYIkJKRouTk4XGTTyQB2AHrWVZeJNLvruG2gndpJ w7Qlo2VZQp+baSMHFAGrtX+6PypksEUqhZIkcA5AZc4NV9Uv4dL0y51C4yIraIyNjqQBmsbRRrOs 6NFqlxqb2kt3H5kcEUaGOIH7oORk9s80gOkAAAAGAPSjaCc4GfXFYtze6hYeGg022XVGTykC4AeY 8Lj270nhLWZdb8Pw3NyAt5GTDdIP4ZVOG/xpgbe1SCNoweox1pFjjRNiooXsAKztevILLRLq4uL2 SyiVPmuI03NH74wf5VVm8UaXYSi0nuJpJ1thOVW3dmZP72FHPvjpQBtNFG+N8atjpkZxQYYjjMaH b046VDY31vqVlDe2kglgmUOjjuDXO6veakPG+laXb6lLb2t5bzSSKiITuXGMFlNHWwdDq6aI0Dl9 ihz1YDmuWTWdQ0bxbb6Jqlwt1aX0TyW10VCOrLyyvjg8cgjFaUfijSZLr7MJ381omljBib96o6lO Pm/CgOpreXH5nmbFD/3scmnbV5+Uc+1ZNv4h0280+1vreeSS3u5PLhYQvlm6dMZHQ8msPTtT1W4u PFccuoyEabKUtcInyjy93PHPNK+9wOov7U3djcWyMsTTRNGH2525GM4/+vVfQdK/sbSLXT2kSZre IR+asezeB7ZP865vTbnxFd+BrXXrbV/tF69t57QTwp5T45IG0Ajp6muk8P6xF4g0Gz1aFDGl1GG2 Hqp7j86fUXQ0tq4xtGPpTTFG5BZFJXpkdKx7nVbO219o5tRnR4rNpXtBEShQHmTOOcdODSWPi3Rt Rnt4ba4lZrqIywEwuFlUddrEYJHp1oGbLRIzK7IrMvQkcin1z2keLbPVNNmvmSaCNLhoVWSNgzkH AAGOScdBT28YaJFayXMl28aRTi3kDwuGjkPQMMZGex6GgDcEcY6Io5z0p3WufHjTRXkMayXJlEbS eV9lk3lVOCQu3JqS28XaLeS2ccF2zfbeLeTyn2O393djAbjoeaANhYo1+7Go+i4p21f7o46cVlT+ JNLtrtLeW4Kl5vIV/LPl+Z/d3Yxn8axvGniX7Ho9wdNvJormG4jjZ44SyAlhlS2MA4P4UdV5g9Dr iiMpUqpU9QRwayLLQ5LPxFfap9pR0vI0j8gRY2Bc45zz19KjfWLG11rUBPqcoFparJNbtHhIVz98 HHJP49KSfxZpsNhqFwpmkexgE0kPksHKkZUgEdD60AbaRRpjbGq49FoWONCzKiqzfeIGM1kQ+I7S XTLW8k85XuIhIIRCxfoCTjGcDPXoa0NP1C01WxivbGZZreZco47j6djQBYdFdSrqGB7EZpPKjKBC ilB0UjgVnalrun6WXW6ncGNPMcJGzmNP7zYBwKZd+I9MsYBNLcM0XlCYtFGX2oejNjOBjmgDV8tA CAi4PUY4NZmraVc38Atba8S1tnVkmj8kNvUjHByMH86rSeMdFiufspupJJTGkgWKB3yjfdYYHIPq Kzz4ts9S0G8vHuLvS4orkwCcW7FlwwA6gjk5HtQtQOmgsoLe0gtEjBigRURWGcBRgVK8SSYDorAd AR0rl9a1mZ/E1toUU9zapLbPK80MDM24YC4OCMc5qzouq2sOlTy3Gty6gYrkwSTSQeWwk4GwKAM8 9OvWhdweh0O0HBwMjpxSkAjBGaxl8T6SYppftDq0M628kbRsHEhxhduM5ORVTUPGen2lil1Cs0+b xbR0ETAxuSAQwIz3oA6Paufuj8qQRoOiKPwrKvvEul6arNczSIqBWkbymIiDdN/Hy/jT5Nd0+K58 jzXkYOiFo42ZVZvugsBgZyKANPYvHyjj2pCikEFQQeox1rHtdTki8RTaJcvvLQ/abZ+hZM4ZT7g4 /A+1X7/ULXTLVrq7lEcSkKW68k4A+uTQBaVFRQqKFUdABigqD1ANZUfiLTJIJpROym3mEMqPGwdZ DjC4Izk5H504a/YlA+6YM0xhWMwsHLgZI24z05oA09i/3R+VJ5aHPyLz14rNGu6eLaCYSSN9p3eV GIm8xtuc/LjPGKI/EOlzWCXsd1vieTylCqS5fum3Gd3tQBp7RnOBmlIB6gGudufEWmXsNo0OpTW2 ++W3IWE5aUH/AFT5Hy5/CrcviXSobw2z3DBlnFuXEbFBIcYQtjGeRQBqNFG7BmjRiO5Xmhoo3xuj VtvTI6ViWnim0uNT1W0kWWBNMIEkskbBTxknPQDGMetWIPEelzTXMH2gwyW0YmlSdDGRH/e5HIoA 1No5JAz9KAi5HyjjpxXKpr0t345srO2uZ/sctjJK8MsJQEgjaykgHua3tU1O00ewkvb6Ro4Ivvuq M233IAJpdA6l3auMbR+VLtXj5Rx04rMj13TpdRbT0lc3C24uChhcfu/XOMH6VV/tqyudV00Rahco biKSSK38hgs6gckkjt1HSi4G15cYkLhFDnqwHJoWONCWVFUnqQMZrh9T8XyX/h1dTsJJrIRakkEm +MjenmbTkkd/bkV1Oma3Yas9xFaSSebbMFljliaNlyOOGAOD61VgNEgEcgEUbV/uj8qxvEOvx+H7 GO5khlmMkyQqqKTyxxzishvE403xTqS393cNYJZxTxRC3LGPJbcSFXIGAOvSktQZ1zxRyKFdFYA5 AI6U+su517T7aCOd5mkSSLzl8qNnPl/3sAZxVyyvbbULKK8s5RNBKm9HU8MKALNFJS0AFFFFABRR RQAUUUUAY/ifTp9X8N3tjasqTzR4jLdCQcgH2OMfjXM3FhqGqeHr9B4SjsL97JrcMGj3SM3ZWB4T PJyR9K72ikCdjj49M1JvENhcGwkjhTSXtpHaRMI5xgEAknoeQDWfFpGtDwt4esW0mUT6dfRNMvmp jYpOWHzcjngdfau+ZgAWbAAGST2qvZXtrqFuLi0uI7iIkrvjYMMg4PI96dxWMPTdOuYde1+O8sS1 jqEiyJMXUqy+WFKkZznr2x71F4L065tEnF1MLiOzd7Oykzk+SrdT75wv/ARWpqMmi6xZ32n3k8M8 MCg3aCTHlgfMN2DkdM/hV2wW0TT4FsAgtfLHk+X93bjjFJDZleN9On1TwfqVpbAtM0QZFHVipDY/ HGKq6lJf3qaJdafaPdWTgtceQ6rIoKDbhiQQM5zg5rppJEijaR2CqoySTgAeuaq6dJYz2gn06SKS 2lYsHibKsc8kY465pgZHgmwvtL8PCyvrQ28sc8pAMgfcC5IIIJ7EdeagvLfVNP8AGx1aCwlvrS6s 1t3ETKHhZWJBwxHBz1Brqu9FD1Dueb2Oh65p+m6LdS6J9rayM8dxYtIhYpIwIdTnBIwOCQa3NR0K e+8Kstlp0Gm3sUwu7W3jAGyRTkbivGTyCR6966e4uIbS3kuJ5FihjUs7scBQOpJp0U0c8SyxsHR1 DKw5BB6GkByuvaRqM/g4WcNq11fzTRSzqjqo3eYHbkkccHH4UxYda0rxDqfl6P8A2hZ6qUkRzIoE LBQpVwT04zwDXY1WvL+0sI1ku7mO3R3Cq0jhQWPAAz3p9QOObSdStda1K3uPDttq9pqMoljuG2bY zgAq6tztBGRjNdwi7I1XAGBjAHAp1LR0sHW559qGiazPpfii3j0uVn1C8SW2HmoN6jZk/e4+6eDW 1aWd8PGz6g9i8dq2nJB5hZThwxJGAc9/SumopdvIO/mYviy2u77wvqFnZW7XFxcW7RxorBeSO5JA xWPdW2uX/hOHQbfTHs5ZbZYJri4kjKRLgBiApJY4zjtz1rsiQOvFFFtwvscEfD9zoGqvDBoCa3pt xbRQJlk3QlF2kMG/hI54/KtLW9AvpG0i70mOGC6th9mmSL5EEDjDY/3cAgV1O9d23cN2M4zzinU/ UNtjlPEel30uo+Hf7PsHng0+68yVlZFCrtI6EjJ57UyG31S08dapqp0e5ltbm1hijaOSLJZc54LD HWutzRmgDmdE0S+PiS/8R6oiwz3MawQW6tuMUa+p6bifTipPF1jqNzb2V3pcQuLnT7tbj7OW2+co BBXPTODkZro6KOwHGa3aaxqumQahb6MiTWt2lwLCd13zqAQwYjIzzxz2qDVNMvdQ0TdZ+GhYzS3s ErQIYxIyowJZzkD6DOa7k0Ag9CDQtwepzeo2eof8JlperQWLz26W8sM211DRliCCQTyOD0zWI+ia 1/wgupaauly/a579pY4vNj5Qyhgc7sdB65rvyVGMkDNBIAJJwB1JpBucrqGm3974o025WzlS3Wwm glm3r+7ZwMcZzxjtUPhtdcs9OttHvNGSN7BWjW8eRWikAyFKgHdk8Z4HeuwVlYAqQQehFLQLqcDp em68Nb0O/u9JlSS3WaK7YzJtUtjBRQcBeOwz6jvVdNB1228PWajSfPuNL1CSY20kiFbqNi2dpyec HIzivRe9GadhnF3OjjULOJn8NzaaJJzJvspES5t2CgCQlTgk9MDPHWr2k32saVb6RYaravdS3LPH JdKyjy8ZK7gDySOpFdPTDHGZRIUUyAYDY5A+tAFbU1uG026FmiPcNEwiVxlS2OAfauGg0nXHvo7u TR7kNJpEtrL5k8ZIlPTA3YCnsB+lei0UhnCW2i6sE8LRvYSRfYrWWK5cSJ+5LIFB4PPPpVOHTdfT QtG0eTRZWk0q/jZ50lTy5Y1LfMvOec9CK9GLKvUgfU0tO+oraWIpd5ibywN+07Q3TOOM1wmm6Zr/ APbGh313pUqS2vnR3bGdNi7uhRQcBfoM+or0Cs2+13StNl8q91C3gb0kkAxxn88dqS0dwe1iTV9O i1fSLvTZiQl1E0Zb0yKxfD82saXpUGkX2kTyz2ieUlzC6GKZRwGyTleOoI/OuljkSaJZY2DI4DKw 7g9DUB1CzF+LA3Mf2pkLiHcN5Ud8elMOhkXdlearrFrDe20yWlrGZfPhm2K0x4wMNuwB7VR0bSdQ 0LxjqS21lM+kX6rKZmmVtk44Y4JyQRjtXS3F/Z2k8ENxdRxS3LbIUdgDIfQetWqFoDMLxhZ3eoeF NRs7K3M9zPDsSNWAycjucCs1NP1NfEcd4dNl8ldI+zFvMT/WZzjGf16V19FIFoYPgyyu9O8K2Nlf W7W9xAhV0ZlbuT1Ukd6paxZ6kfHOk6pBps1xa2lvNHI8bxj5nxjhmBrq6KfW4krKxxmoeH9S8Ta3 /aF5F/Z9va2ssNpEzgyGRxgu23IAHsad4Ws75GtINQ8MW9nc2CeW17lGD4GMx455xznGPeuxJoBo Wg2cpoOg3mma5fRyBf7LilaayGeQ0g+cfQdvrVbTdO1W3uPFckumTKNRlL22Hj+ceXt/vcHPrXaU UraWDrc4jSrfxBaeBrXQ4dHkhvltvIaaaWPyoyeCflYk9emPyro/D2jR+H9Bs9JicyLbRhdx/iPc /nWpRTF0OT1fT9Rl8VteQWMktv8A2VLbiQSIAXY5AwSD+NUNN0bVoI/CCy6bIv8AZodbr94h8vK4 Hfn8K7uiklYb1POv+Ef1yHQRGmmCWfT9Ue7SCSRSt3GzE4HJwcHvjmrWqaZfajoObHwyLGaW9gme FGjEhCNks5yAfau7op9bgczdWd+3jePUUsZGtU054TIHQfOWBxjOfxrFs9D1mDQ/Dls2lyCWw1Ez zr5kZ2puY5+9zw3avQMCijpYNzhdK0i9s7qbS73w3b3sX2tp4NRfYVCltwLA/NuXoMfpVG60fX4f DmqeH10ma7eS+NxDcpKmyRGkDYOSCCPpXo9HektwepxWqWGuvrms39hpuTPpscMBlaMhpA2SuM+h 7jFVV0PV7i91lxps8SahpSwxvcTozeYAchsE469uPpXoFFMdzgX0/WLeXR9Sbw+b1IbEWVzZvJGZ ExjDrk7TyPWuu0a2+yaZFF9hhserfZ4FAWPJzjjjPrWhRQScldw6zpXi29vbbS21Oy1KCNCEkUGJ 0yOQx+6Qe2aq32m6nZeIprpvD0Gr2l/bxxsiMg8h1BGMN/Dg9vTpXcUlCGcrpOmXtr4xnum00W9m 2nxQI8ZUIrKSSqrnOBnHSsefQ9bPg3VtHXTHeeS+eWIiRNsimQNkZPTHrivQqKOodDmbi21B/HOn 6gthIbSKxkieTenysxBxjOe3pWG+h66ljdXEGnsLm31s38MDyLi4j44yCcHg4zivQqKQHJalJrl9 psdzb6I1uzXcbSwbo/tBjH3mDZ2humOc4rGbQNaWx1BU0qXI1iK9ijM6FpYwVyASx5GO5H416NRT 63DpY4WXTdQt9f1EzeGotVtNUZJUd2Q+Q20KUkDfw8ZyM0+/0TUV1n7ZpVtNY3ayxKzRuv2W6iAA JdM8EDI6Z6Yrt6KAOXltnvPiPBdRj93p9gyyN6tIwwPyBNXPFEeoyaRjTLfz5RMhdBt3FAfm27uN 2Oma1YreKHd5aBS7bmI7n3qYdqXQOpwMWhXrf27FeaFcS2l9dQyxj7SpkCgAFg27O9cZ6/nUn9g6 jLpK2mpx315HHeM9rdJKqXdsm35XJyMnPHriu7ooA4az0vxDY6ho+r3kbXz28M1tcIhUSBWbKPjO CcAbsVBJ4f1mwmTWrO086ddVkvGsPMAJjZNmAem7v1rv80Z/nTvrcPI5DWLbVtTstPmTRWiddTiu JIFkj3oinlmOQCfYGs7WNM8QX09xu0qSVotUiuIWimRImhUjnbnJfjnd+Feg0UdQeqOE1DQNYvJf E1vHa7BqPlTW0zSL5bMij5GGc8kY6YxTbvR7/wAQaBfRp4dh0a/e3Cb3KFpWBB2Bl/gOO/rXeZ5o J5pW0sBx9qNY1DxbpWp3GiXFnFDZyQzb3Q7HJHTDHI4rqb60iv7CeznXdFPGY3HqCMVYopvUFozz 2Hwv4h8rTbuSZft0BNhKQ3Bs+m7/AHuA1buoaddnxfodxbWbNZ2cUySyB1Aj3KAvBOT07V0tFIVj z06LrS+G30z+ypGlj1cXAcSph4/O37hlvTscVv6TaX0XjDWb2azeK2uo4BFIzKdxUEHgHI6iujo7 0+odDnvGVheahoiJZQfaJYrqGbygwBcK4JAzx0FZ1xYapPrWt3Y0uVUvNMSCLMicuN2Qfm4+8K7I 0UD7HnsOkavpculXcvh/+04/7Mjs7m23pvgdP4hk4IOSOtdppVsLTTYYBaQWe1f9RAPkjyc4GP1q 9RQKwCloooGFFFFABRRRQAUUUUAZfiC+uNN0C/v7QRma2gaVRKCVO0ZwcEHtXNjxH4gtbzTherYt Bqts7wGKNswyKm/DZPzAjPTFb/ipHm8K6pFDFJNJLayIiRoWZmKkAAD3qlomhpJZabc30txPLb2n lRxzIF8rcoDcYB3YGMntS11HpoVLHxNqF0vheR47cLrCMbhVQ5Vghb5TngexzWHpWqazoPh19St1 tJNMh1KZJ4CreaVaYqWVs4BBPTFdJaeCreyk05hql/IumSM1qjFMICMbTheRg4yefep4PCNrCrW5 uriSyNwbn7I+3YXLbuuMkbucE9ael79CdbWMj7RLZ694yu7dIzLFbQyKsq7lbEROCAR1q7aa9faj 9hsLP7PBdSaal67OhKjPAVVBHGQc88DFXn8LwPc6tMb26B1aMRzAFMIAu0bfl44J65qrN4Mt2Gnv bale2l3p8P2eO6iZd7x/3XBGD09KXUpm3YNePpsTalHFHdlP3yRNlAfYntXGfD7U5bvSrbTbGWGM WW9roSoSxDOSoQZHHXLcjsK7S3tFtrJbWKRwAu0Ox3NnuxJzk96wrHwPZae1hJa397HLYB1SUMm6 RGOSjfLhlzkj0p9RdCC31/XtSa3vNN09ZrJ7oxSKdqlYwxUuGLZyCMkY9velh8Raosuq6bc/ZRqd tcJHbBY2CyRvjaxG7nvnB4wat2ng+3sdSkuLbUL6O0lmM7WIkHk+YeSRxkDPOM4zTLK3j1rxKmuS aXc2bWUTwI1yoVpCTycAngDOD/tGhdA7mh4iu7jTvDd9eQCGSe3t2kxKhKPgZIIyOv1rG/tvWbjW NP060azhS7003IeSJmKMMcYBGRz7V0Oq6dHq2mXGnyySRx3MZjdoyAwB4OMgj9KoQ+GIYNQtL5b6 6MtraG0jB2YK8ckbevA9val1B7D/AAxqs+ueHbbULhY0nkDK4QHaGBIOO+OK4u8uNSuvBOpzXtzH dMmsCNPkK4KzgcnJ46YAHHvXd6Ho0Og6Ymn28000cbMytMQW5JPYAdT6VmS+CrSWzurP7fepBc3X 2oorJhH3bsDKnjPPOTT63DpYqS+KdQ0mfWoNRFvcNYxQywtChTPmHaFYEno3fuPStPSrvX5NWkh1 GzUWRiDxXAAUh88qVDH6g0258I2N7dahcXdxcTjULdbeeJioXaucEYAIIJznNT6LoLaOP3mp3uos i7I2unB8tPQYA9sk5PFCAbrmp3dhJAsOyCOQMXuZIHlVCMYBCkYzk8k44psGq3rw6VM32VlvJTHK YWLL90lSp/4DVq90ya5vBd22p3NnII9hVArIwznlWB556iojoSLp0NtDdTRSwSmdJ+C3mHOSRjHO 48Y70LYHuZutXNxPo+qR3UEM8tlcwmELwGJKMvXODzjNaMF3qdvfwQamtu63Sny2gDDy3AztbJOe O/HTpVd/CqS2t7bzarfyi+kSSZiyAkqB0+X5QcDp07VcttJa3uUuLm+ub1oUKwiUKAgOM9AMngcm gCnB9vg8TwG+Wzka5t5FWWFGVlVCCFOSRj56zL7xlMl5efZprOOKxlaM28yO0lwV4bDDhOeBw2eO la0EtxqOuW1wtjcW8FrFKrPcALuLbcADJPG05PuKdNoMv2qaSz1S5sY7lt8scSow3HqV3AlSe/bv 1pa6BoOfUry9mht9NEcDvbrcvJcRltiscBdgIJJIPOeMd6o61ca+PDbyH7PZ3i3SKSpZlZPNUKRg gjI6g9sitO60gyyxT299PbXEcflmVcOXXrhgQc88/iaWTSEm0uSwmu7mUyNuaZ2G/cCCCOMDBA4x imGovk3smmXMepSQtIythrYMgAx65zn8a5/w8BKNObTRqIk25u3ufNETLg/3+Cc4wR2zzXQQ6Zdr bzxXGrXNw0y7Q5SNfL/3QF/nmn6Tp7aXZram9uLtUGEaYKCo9PlAFLqwZnf2xqA0u2uykG83XkzK FOCN+3K88evNVbJdUg1HV00uG0igiud22RT++YqCQMY2/U557Vbm8MecxT+1LyK2Wf7QkMewANnP JwSRnsfWnDw28dxdzQ6xfRG8fdcD5MNxgbfl+Xjjikuo2Raz9k1Xw5BqDW6s4aKSIuoLRkyL0Pat jUVneylW3MQkKkfvQSuO44INUb/QVvLKKyj1C6s7eIAeXAqYOCCCdyk9QKsSafcvp4tv7WuhJnm5 Cx+YR6Ebdv6U3qrIS03K1lfpaeFYLzyFVUgUrDGeM9ABn3pYH177XCt0lpLbTg+Z5QKNBxwOSd31 GKdY6Gtrpb6dNe3N7bsmwCfYCo9iqjnvzTrXSbiCVGm1e7uViGERgijpjJwBuP1pu1xbI5nS4xeX CaZN9ttrP7W7rO07/wCkyKT8itnKgDnHG7t0q1qHi6aPUbu3tLizgSxbyylxG7NOwGSAV+4O2TnN a0Xh1Y9OezbUbuQmfzo5mCb4nznK4UD16g9aW40OU3UlxY6nc2TXGDOI0Rg5AxuAYHDY/D2o1K0G DWLmZtIuY40isr7iTzFO9GIyo69+e386ksmm1qC8W9CG1+0NHA0LMjOq8ZJB9c9DVXxGJE0I6bDb Xt5LIgCTRruZCCPmLdiOtaiWBj0uOztriW12IAskYXcPX7wI/SjcSMjR4zpvhB762LyXPkNKTPKz hiufUnHTtVnT9Q1P7TZpqItsXsJkRYQ2YiACQST83Xrx9KdbaAbbRp9L/tW9liljMau4j3Rg5zjC Ac575qdNI23FhMb64Y2MZjVSExICACWwvXgdMUdRdDG/s671LxXeG8j0+5gtzHsWaAsY1Iz8uTgH NXZb/Wby9u4tIFokNkQjfaFYmd8ZKjBGwdtxzz2qxDocsGpy3y6vfEzMpeIiLYQOAPuZx+NNu9Ak lvJriz1S6sftQH2hIQpD4GMjcDtbHGR/OkUW9LvhqmlwXsS+X5ybsNztPQ/rXEWst7BpHiy+l+xX T2l9NIqTW5Zd6gY/i6Y7frXe2dpBY2kVrbLsiiUIo64rFXwjbjT9UsTqF40eqyPJMxKbgW67flwK HuLpr3KcviDV70vaaPao1zBZxTMGUEM7ruC8uMD35qtPeSJ400u/1C2+zTJo00s8QIbYQQSMjg1p XHgyB7q3u7XVL+zuYoFt3lgdQZox0DDGM+4watP4Zs31W3v/ADbj9xataiEsCjI3XORkn3zQ/IDm b6/v9Xk8I6rOYFt7rUFkSFUO6MFW2/MTzx7CvQRXKweBoLdbGFNWv/s2n3AntYSUxF1+XO3JHPc1 v2VnJaG4L3k1z50pkHnEHywf4VwBxVdBal2ikpaQwooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKS looAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAoqC4uIbWFp7iVIokGWd2CqPqT0ql/wkug/wDQasf/AAIT/GgDUoqp a6hZXzSpaXUU5hbbII2DbDjODjoat0AFFMZlRS7MAqjJJOABVBPEOiyNsTVrNmzjAuFPPp1oA0qK TOaWgAoqvd3trYwma6uIreMcb5XCr+ZqvLrmkwLG0up2kSyjMZeZRvHtk80AaFFVrS+tb5C9pdQz gcExuGx+VWaACiiigAopKrQ31pded5NxHILdykuD9xh1B9CKALVFZcPiHR7m8Wzh1G3kuWOBEJAW PGen05rUoAKKKKACiiigAoopCQOpxQAtFFM3ru2bhuxnGecUAPopKWgAooooAKKr3V5b2URmuZli jBxuY459B61Bp+r6dqpf+z72G68vG/ynB256dKAL9FQXN1b2Vs9xczJDDGMu8jAKo9yaEuIpoFuI 5FaJl3q4PBXGc59KAJ6Kq2N9a6jbC4s5454SxUPG24EjjrSpe2st5LZpOjXMKq0kYPzID0JHvQBZ ooooAKKqHULMX4sPtMf2ooZBDuG/aO+PSrdABRRRQAUUUUAFFFFABRRRQAUUUUAFFFQ3FxDawPPc SrFFGNzu7YCj3JoAmoqG3uYbu3juLeRZIpF3I68hh2NS0ALRRRQAUUUUAFFFVLa/s72SeO1uYpnt 32SqjA7G9D70AW6KSloAKKKKACiiigAooooAKKr3d7a2MXnXlxHbx5+/I4Ufmajl1OxhsxdyXUIt 2GVk3ja309aALlFV7W7t722S5tZlmhkG5XQ5DD2NT0ALRRRQAUUUUAFFFZ7a1paJdSNqFuFsztuG MgxET2b0oA0KKZHIksSSRsHR1DKw6EHoahtry2vDL9nnSXyZDHJsOdrDqD+lAFmiiigAooooAKKK jmmjgieWVwkaAszMeAB3NAElFRQTxXVvHPBIskUqhkdTwQehFS0AFFFFABRRUU0sUETSzSLGi8lm OAPxoAloqjBq+m3Ns91BqFtLBH9+VJQVX6nOBU9tdQXkCzW00c0TfdeNtwP0NAE9FUpdW023vFsp tQt47p8bYXlAds9MDOTT5L+zhuUtpLqFJ3xtjZwGPpgUAWqKq3N/Z2bILm6hhaQ4QSOFLfTNWQci gBaKKKACiiigAooooAKKKKAK9zbw3UZinjEiEg7W6ZByP1FcppdtDcfELxPBNCjxPb2ysrLkEFWy K7HvWRZ+H4bLXr3WEvLmSa9VFlRyuzCghcYAIxk96A6HIyX2o6Jc+K9Q077MsVpdRO6SxljIPLQF QQRjjvz9K2r7XdZurq+t9Cs0lmsUjO2QAiR2UNtyXGBg4zg8/SrFz4PtbqLVoXvrwJqzBp8FPlIA Hy/LxwB1zSXPg+GbUl1C31S/sp2iWKcwOALhV6bhjrjjIwaOi9A6m7bSSzWsUk8JhldAXjLA7CRy Mjg4rkvAtla3vh/VLa6t45YZNSuVZGUEEbzXXrCscAhiyiqu1cfwgDFc/Y+EFsLOe0g1nUlhuJGk kUNGCSxy2CEyMn0NJ7i6L1Oc8Ja9eWelLpMG+5P9pz2llI+G/coN2eSN2Og5/lWtca74l0yxjvNS s7eCGO/ENw7LktAxAEoCudvJwQc+taV74N0u50i002286wSyfzLaW2fEkT85IJznOTnOc5qymgwN o1zpl5cT3q3Sss005Bd8jGeAAMcYwOMUX6jMPxhcz3ngvxG7GJrREKQYUgnGNxJyc85AwB0qPWEX +1/A/wAo/wBa/b/pjW7eeGrW88NHw9588NqYliZ4yN5UepIPJxycVFd+FYryXTJW1O9STSyTAyGP k7dpLAqQeKfUOhkeKI10vxt4cvtPXy7q9uHt7hU486Lbn5h3x1zXQ+INWOkWMcioGkuJ0t4gx4DO cZPsOTTLfw9bRaoNVuJ57y9VNkctwwPlA9QqgADPc4zU+t6Na6/pcmn3m8RuQweNtrIwOQynsQaW ysHUyr/VtZ0fcl5HbT/aLmOCykjBBYsCW3KT2wccjPtVLUde8T6XpV5cXFlbo0NzEkEsgAEyOwUg qrHDAnr0PpWjN4Pt7vSpLHUNQvbuVirLdyOBJEV+6VwAARz25zzmkn8JR3mlvY3mq387SSI7XDMn mHacqPu4ABHpQgM+WXxDH4u0ezur+0KyxzuyRQMFIBXHBbOcH6e1VdU1XUL7wb4qBa2gks5poN0c RG9AB7/eOev6V099okV7qVhfm6uIrixDBWjK/vAwGQ2QfQdMGqZ8IWr6dqtgb678vVZWlnOUyCcZ C/LgDgetHS3r+YJ2dypHc3Wnav4dheOyk+3xsksywbZAFTIAOTxzVjTNW1jWIbPVLJbVrGeZlkhc MHSMEgMGyQWyOmO9XJfDcU11pdy99dGTTM+V9z58jHzfL6emKrWPg+1026la3vr0WLymUWBceUrt 1xxnGTnGcZ5psSVijZ+JtSfW9OspjbOL7z1bykJWFk6YfOH9Djv6VT0PxBqsGhwvPMl3dX2py28J 8vBUh2JJBYAjC4A4rWsfBFrYy6cyanfuNMd2tldkwqsOVOF5Hv196STwPp8mmTaf9rvFia5N1Ayu A1tIW3ZQgepPXNAy/oVxrU/2qPWLNYTHLiCVSB5yY6lQTg9utM1vVbyxuYYojFbQshZrmaB5Vzn7 uFI28c5J/OrelaY2mQlZL24vpnOXnuCCzeg4AAA+lR3ulz3N6Ly31S4tH8sRsiBWQjJOcMD83PWh giCPU702+kTsLbF7II5hG5YcqxBRhx/DVHW7m4uNI1aK6ghnksriEwBRjdkoy9c4POM1qPoMY023 s4LqWFrZ/MjmwC2/nkgjBzk5471UfwqktrfW82q38ovnR52LICSoHT5flBwOnTtR1AsQXep29/bw 6mtuy3QIjaAMPLcDO1sk5478dOlV4ft8Hie3N8tnI1zBIqywoysqoQQDkkfxVbttJa3uUuLm+ub1 oVKwiUKAgPXoBk8Dk1XgluNR1y1uFsbi3gtIpQz3ChdxbbgAZJ/hPPvS6gZN94ymS9vfs01nHFYy tGYJkdpLgr94BhwnoOGz7Vsvqd3fSwW+mrHA8luty8lwhbYpOAuwEEkkHvxjvSTaDL9qmks9UubF Llt8scSowLdyu4HaT37d+tT3WjmWWKe3vZ7a4ij8vzVw5deuGBBzzzTW2oPfQy9ZuPEA0SNz9mtL oXioxBZldN4AIwQRnuD9K37IXqwkX7wvLk8woVXH0JNVJdHE+lvYy3tzI7uJPPZhvDA5BAxjGR0x irFhZ3NsJDc6jNeO54MiooX2AUD9c0l1BnO+K/tp8TeG0guIkR7p8K8RbkIeTgjPH0qM+IJNGn1+ L7JaKljJCIRBH5e9pMfe5weT7Zrd1LQYtT1KwvnuriJ7BzJEse3aSRg5yCTxVabwjY3cmrNcz3Ey aqqrPGxUBdowpXABBGPehDM3UbnXpNL1231KzUWf9nyNDcAKpLFTlSoY9PWl0fVbmRdJ0OxaKOVd MS4lllTdgdFAGR361dt/Cgj0u4sbnV9Qu/PiMAlmdS8cfovGM+5BNJ/wh8CT6fcWmoXdtdWMP2dZ 12FpYv7rgrg/XFPqxEHw3DDwhH5m3d9pnzt6f6w02717UrXWNet4LOK4NjbwywiGI+Y4Y87ufmwM nAxmtjw/ocPh7TvsNvcTTx+Y0m6YgkFjk9AO5qvN4Zjk1O+1BNRvIZ76NEfyygEYQ5Xb8v8APOaH qCF8N6yNbtprlL2C7iVwEMUZjdOOVdSSQ2fpWf4p8Q6jopvJLc2wjtbYTJGVaR5TnncAfkX3Petn TNHh025uroO0txeMrTSMANxUYHAAA4rP1Pwfa6re39w95dwrqEAguYo2Xa4X7p5BII9jz3oBeZRn kkufH2lzQ7Eml0eRlLDIUkgjPQkVTj8a6ksGlPdi1iaS+a01FRE37kgkAj5uBnHXPWuhg8NwwarZ al9supJrK1NqoYrtdPU8Zz+NMuvCGlXn9reYjf8AE2CifB6Y/u+nPP1pAQzaxqa28U6vaJFcXhjj coSwi5wQoPzsSOg7dqyovF+rtoVprDx2wt49Qa1vyYmysYbaJFGeOcZzW/qHhy3vl07y7m4tJNMb dBJCRkcbSCCCDkVl3GkxaHpc+i2tpqGpx6s8pywVo4WbqWPGBk570wJtR8Q6haWl5fwQrPYw3KxK 8UJd0QffkwD8wB9MfjWp4f1H+1NMF4Lu2vEkdtk1sCFZc8ZBJw3qKZDoK22jWOm2t1Laiy2bHiIJ JUcg7gcg1PpOk2+jxTRwEsZ5mmkY4G526nAAAoA5u91zxK13r0Wn/wBngaRtkUSxsTKpXcV68H3/ AEpbfxLresapZ2+m/Y4IrzT0vFM0bMyZbDLwfrg0llpdxfeJ/EgkkvbS1u/KX5YtqzKEw2GI69uK 24PDlra6zBqVvNPGYbUWqQKV8sRg5A6Z/WhbL0Ay7XxBr2pG3vdN09Z7F7oxSIdoIjBILht/XI6Y qKy8Yyvc3S3jRQTWUc0lxYSRMkoC/dZCT86n1Aq9beD7ay1Gae21C9js5pTM9h5g8kuep6ZAzzgH GanTwtbvPDLeXE16bdZEiE4XhZOGBIAzx0pdB6FK11fxJO8FybKL7DcWrS+aQF8l9u5eN+WB+gql pXinW7geHrm8+xmDVy8bRxRsCjgEhsk8jjpj8a1dL8IR6XG0CarfzWyIyW8Mzqy24P8Ad4ycds5o t/BtpbwaRAl/dldIkL2+SnzEg53fLyOT0xVaXJ1IfBNzqN5Z381/drcbb+ZFIjKkYbHrjHpxW1rQ zod+D/z6yf8AoJrHn8MSWmnXsGk6jfQPdXPnqFdQI2Jy2DjO09+p9K35IBcWTW853iSLZIRxnIwc VLV00Ut7nDaBq2s6TpvhmGdbSTT9RjW3jCK3mQvtypYk4YHHOAKt2/i3VJdE029eO18y41Q2UwEb YKbyuV54PHvWvp/hm3sPsSSXU93Hp4xaJNtxHxjPABJxxzVM+BbYIkK6lepBHefbIoQUxG+cnHy8 jJ759qbdyVsL4YudSudd8QLeXaTRQXnloojIKjaCMHPv6Vdv9Uu315dF09oop/srXLSSqWGM7QAA R3/Sp7HQ4dP1S+v4Li4JvnEkkLEbA4GNw4z098VBrHhqLVr+21CK9ubC9tlKJcW5GSh6qQQQRS7D KN/rWu2NpbrcCzt7n7LJLKEVpi0i9FVBg7cck9qq23ifWdUvNIgtRZwDUtOa5ZnjZvLcYHTIyOfb 61pz+Ebaa5iuI728hkS1a2kKOpMyMcncSDznuMUmneDbXTbiwni1C9d7C2a3h3lCNrevy9aNRlrw rqs+teH7e9uVRZ2ZkkCfdJVipI/KuVWfWrHVPFl7o/2M/ZrhJZI7hCfNAjyVBBG3jvzXYaHosOg6 ctjbzTTRh2fdKRuyxyegA6mqc3heCW7vpkvbmKLUSDdQpt2vgY4yMjI6803voJbIzP8AhKdV1aOX +wrNWlhtYptkiht7SLuCnLLgcYzXSw3Uq6Ut5eQGGVYfMlhDA7CBkjNZN54PtZtQjvrK+u9MmEK2 8gtXAWWNeikEHp0BGDW5HbxR2wt1X90F27Sc5GO9J7eYu1zmLHW/EeoCyvoLCJ9PvI2d2O0eSMZU g7st7jAqhZ+KfEM1joN8/wBgK6rObd4xGw2NlsODu5Hy9MfjWxpng+HSXaO31O/azXcYLR3BjgLZ 5XjPGeAcgUsPgy0gsdLtEv7zy9Ln86Ekpljkn5vl6cnpiq0DUyLrxZrdjpeql1s5rvTb+O23CNkS VXxg43EqRn1NLqmua/Zy6xpd3JarMunNeWl1BGwAAOGUqSeR6/pSeLPDhtdF1OSza9urnUryGZ0V A5QqwyVCrxgDvmt5vD1rcm7lvJp7mW8tvszSPhSsZ7AADHqaS2K2ZlR6zq2lW/hyW8ltZLC+RIri bymDxuyAoSd2ME8E10Gj3V1fW81zPs8p5mFvsUg+WDgZ5POQaw9V0zOjxeEPst9qEc8IQXcqrsiU EY3MMYIA4wK3l03yrq0khup44bWIxC3Ujy34wC3GcjHHNAjJ+IgB8BatkZ/cf1FZ2oreN4h8JxwT xJG0EhCSRFhkRc55GeK6TXdGi1/SZtNuJ5oYZ12uYcAkfiDVaTw3HJe6ZeNqF2JNMQpF9zDAjB3f L1x6YpLf5iexNrEraN4du7nTooYmtoXkRCnyZGT0GKwE8W6nYzWk2qLbPbXemPe7IEIaMooJGSTn OfQYrqdTsI9T024sZZJIkuIzGzR4yAfTPFZQ8JWZnspJLq5mWytWtFicrtkjYYO75eTgdsUalFP/ AISLU7dtDuboW72ususeyNCGgZ13Jzn5h2PAqhbeKtdNnBqE32Ewf2qbGWJImDMN+0MCTx9MGt2x 8K21kLONru4uIdPYtaRylSIjggdsnAPGSarjwVZjTvsI1C98r7b9tLZTd5m7d/d6Zpkkn/Ca6Lda ldaPY3wbVIEk/dPA+0MgJOTgA/gaytL8Ua5cDQLi6NmYtYV0KRxMDE4BIbOeRx04+tdjPbLPBJFu KGRCpdQNwyOo4rEtvB9raw6REl9dsukMWg3FPmyCCG+X0PbFIZmW3irU5tI0a8dLbfe6kbScKjYx vZcr83H3feqN4o8j4gcD7q/+iq2f+EGtYxDGup3ywW959rt4lKYifJYgfLkjJPXNWpPCdtKusob2 6A1nHn8r8ny7fl+X09c09Lh0saOi/wDIB0//AK9Y/wD0EVxeq63q03hnVJI5YLaa31cWu6GMjem5 Rzz1O7k/yrurO0FlYQWiSvIsMYjV3xuIAwM4AH6ViP4Ns5NNv7F7y7Zb66+1M+5Q0cmQcrhcY4HX NJgbUsxs7B7i5ZXMMZdyowDgZ4HasOy1bWLi0tNXdbVtNntmnlVQRJCNuVwcncex4rfW3H2XyJWa YFNrs+Mv65xxWJpHhG30j9zHfXk9nHkQWkzgxxA5yBgZI57mh31BWsUF8U6imn6PrEiwPY6nMkRj VCHhDnCNnPOOMjHeqsXivXRaLqE32H7PHqxsZYkibcy7woYEnjrnoa2bLwjaWcdvb/aZ5bO0m822 tpCu2Juo5xkgE5Gaj/4Qq0/s97H+0L3y3vftpbKbt+7d/d6Zpi1KNrqWsRap4pk+1W0wsnRYI5hs VPkyMtngcnPr7U+HxLqEx1y3zbytY2i3EMjQMivuByCpPI461evvB1lfSam0t3dImphfOjVlADKM BxxnP6UieEIhNeTyapfSy31qLeZmKcgZAIG3GcE9sUkPS5Ri1/WJ7jw/a2osohqdg0zM0THy2Cqe Bkcc9PbrUC+Nb2LRbO8vhHbo000N1eJbtJHGyMVUlQcqGx15xW1B4Utre50udL67LaXbtbwglMMp AHzfLycAVHaeE00+Hy7XVbxU3Ss4cRlW8w5bI2+vSmHU2NOna50y3neWGVpIwxeA5RjjqvtXMxeJ dSXXNPs5mtpEvbmWBliRiItoYrh84J4GRXSaZpltpOlw6daqRBAmxAeuP8msO38DWtsbMJqd95dh cPNbpuTEe7OV+7kjk89fQ0dRLYzU8Va8todQl+xGCHVjYyxLEwZ13hQwO7gjOehruSAwIIB9jXNn wVaNp0tidQvRHLe/bWIKbvMzu/u9Mit+eF57Z4VuJIXYbfNjxuX3GRj9KOg+p55cxQ+H/FEukRTG Lw9q04FxtHy29wRkxhuwfjPpntmvR44khjWONFRFGFVRgAViXPhSzvPDL6DPcTvBJy8xK+YWzndn GM574qzBpEtulin9q3sq2YIPmMuZwRgB8KM49qXQOpzc1lf6D4ohv76Gy1S01C8CCf7OFuLRm4QB snKjAHas9ma58HeM724JNwl7OFc9V8sDy8emMAj612FpobQyo91qV1fiKQvEtxt2oex+UAnHvUd1 4Ys7mW6LSTJBeyLJc26kbJWHc8ZGcAHHXFFg3Od0KSXV9U8Ryaku5lsLeMK/QK0RZsfUk1u+Bbme 88E6VPcsWkaEAsepAyAfyAqze+Hra7u5biOaa2e4gEE/k4xKgzgHI4IyRkdjWna2sNnaxW1vGI4Y VCIg7ADAFPcRMOlLSUtAwooooAKKKKACiiigCrd3H2W1ln8p5BEpYomMkD0yQKwofGlrJpEWsS6d fwadIu77Q0asFX1IUkge+K3NSP8AxLLr/rk/8jXJeHb+ysPhTaT30ieQLIh1JzuzkbR6k9MVPR+V g62Oo+3+ZJaG2ge5t7lS32mJgUQYyCecnPbFX6818MwahpSeDLO6nnhaWK482AuQuANyBlzjIBq1 YXF0mo/2fqvnSm7t5zbXtvcs0N0vB5XOUYDHTjrg1UtAWx2U1+fJgmtIJLxJpAhMRGEBzljk9B7c 1erzPT2+x+C/CclrdzRtJfQJIFuGIZTnKkZ6dOOlLqxuVg8XXSaleq2nXCPbAXLBYztUkYzyOTwe OelDWrXYF08z0uiuG1q6vJ9Xu7ZriYiTTFazS3m2FJjnlsEck4wTxgGlsVurDxPp9jfX87eZorNc B7lijSBhlhk9eTyO1IDrrq5lgeBUtJZxLJsYxkfuxgnc2SOOMcetTsSFJALEDIA6mvOtO1C7l8Pe ErltQuHkm1ExSOZyfNX5+G5+boOvpV+C8vLTxVCmoedNbXN7Itpe21wWjzhsQyx5wMYPIGMin1Bn TaHrMWu6at9BDLChkdNkuNwKsQc4JHUVpivLtLDWejaPqFveXCSya48DKJzsZGkfKlc7T0znGfet G3uJtauLqdvEC6feWWpsjRYYsEV8KhXcAQy47dTmhag9DrNc1mPQrAXs1vLNH5iRnysZXcQoJyRx kitLPGcH6V5hqV0us+DrrU7y5lF7HqqxvD5xAiCzABNmcfdwenXmvUFPyD6UfZuHUxtL8S2Orane aYqywXtkR5sEwAbB6MMEgirWn6it7cXUItpomtpNjmTbgnAPGCexFcrf6FNqV5f6rpEiw6zYXe6B 88SjYuY39j+hqvba+mo6Rd3khudPlutUit2gU7XMgVQ0ZbjAJB564pLW3oL/ADPQqK8wub+8Xw9r sY1CWJ7PV444jHcljGpZMruPJHJHNaE9njxBrenf2jfC2XTUulT7W+Vl+b5g2cgcA4zj2oeiuUtT v8UV5zZ6tcakNDsb7U/s6XmlCUSyMy+dLnB5DD5gMHGfU12Ph2OWHRLeKbUv7SeMFTdbdvmYJx3O frnmm1YSZYmvkjvY7NQXnkUuEUjhR/EfTngetZVt4ujuze/Z9J1CVbCZoZyqoSrL1AG7J/AVW0SS STx74jM2d0SW6Rg9k254/HNQeCpo4rjxPJJIiIurzEsWxgADk0v8gNC58Y6XB4f/ALej86608HEk kKjMXODuUkEYPUYzV651q3g0qPVIle6t5dhVoMHIYgA8kdyK4nQ4/N0TxFfKmNP1DV1ktg68OnmI CcHscGn6rBc+Dpm02ON5dB1O5j+zY5+xymRSU/3DyR+VNa28xPr5HcwX8ct49k6tDcIokCPjLKe4 xwfT2q9XK+I2ki8a+F3hyGkknjkx3TYCc/iBXSwzQ3EfmQypKh43IwI/MUDK2r6ra6Jpc+pXrlbe 3Xc5AyfTirUE0dxBHNEwZJFDKfUGuf1tZdY1OPTIbeG6gt0Ml1HJKUBLAqoOAexJx7iud0u8ubXw LruhXMzQ3+hxSRq8cpVtmC0bBuDjHH4Ur6NhbVHo1QXVx9ltZbjy3kEaliqYycDJxkgfrXGaQ01p 4l0ULfXEwv8AS2knWWYuGdduGAJwOp6YrsNQP/Erus8fuX/kaJXSYLUwn8a2KeH7XXPsN6bS6kWO MYTdljhcjd3NXD4mtYb63sdQt7nT5rk7YDOq7JG9AykgH2JzXDysv/CoNA5H/H3bd/8AprW/8SXW 70e00q2Il1C6vIjbInLKVbJf2AHeqejEndHaUV59NcXGr32rwyeIBpl5p10FiyW3IgwQdu4Bg3PY 5zViea703xJeaS11dSLrUSPZO0rnymHEgXJ+Xj5hj1pDOhn1+GDxHDoZtbhriaEzI4C7CoOCc5z+ lVLfxZHeSXyW+lX8osJjDcFVQ7WAyQBuyfwFZ8yLB8UdJhDltmkygF2JY/MO560vgyWOPUvFUkki Kq6s5LFsYAUcmpTEzotJ1iy1uxW90+YTRNkE42lT3BB5BHpWhXFeAFMtz4i1KBCtje6gXtTjAcAA FgPQmrmu6gI/FOlaXeTtb2V3HIxYSGPzJBjau4YI4ycZp9vMfc6miuEuLr7Ld6Tox1p5LGcTgXdw 5/eOD8qbgRnAPHPPvVa4tbmO48O6a3iG5u0lu54ZJ4ZGj3oFJCnk5I6bs5pgd69xGJHhVg0yJvKK ecdvzqhNrS2WlQXt3ay28k7rGtuxBfexwF64rmbCwt7TxlrsK3FzujsIQjPcuWJ2nnryazp/9P8A AnhW4u7maWV76FWczsC2WbOTnr79aOodDuNL1W41C4uIp9Iu7AQHG+fbtkP+yQTke9atef6tqV7o +q+KGtLi4kFrp8EkSPI0gjJJDEAk845q5PNp1nplzqsHiK6EUunbmWOXzcdP3i5PytzjsPyoA7J3 VFLMQAoJJPAAHWkiljnjWSNgyMMqw7ivN2mmeXxDp0txL5B0VZli+1NIdxB+bPYnjIHFTW10FTw9 o51AWtpdad5gkklch5cD5d24dByBn8KAPRaWsfw1DNb6NFBNqn9pvEzKLrbguAeB1OcdM55qpraX V1qSRQSPMkUO57WG7MEgYnh8jqMcYJxQ9AWp0VVL6+g06Hz7pmWMsFysZbBJwM4B/PpWJbzu9noV wl5cyK8pjdpjgyDn74HBORVHVbkJoniKNNQYpBMgWR33+USVJ656elLrYOh2lVvtsR1BrHDeasQl Pynbtzjr0rIhibT9XtIYL+a5S8R/NWWYydBkOD/D9BxSR2bad4ls0jvLuWO4jlMkc0xdeMYwD0o6 gdDRXAC41zUGvb2OO6W6gndIyL4JFCFP3Wj6HjklgTzW8wfVdU+yXtzJCkdskojt5jH5jN1bcpBI B49KYG5LNHCAZJFQFgoLHHJ7VIK5HWdOWTQLSGXVri6MV8im4SXYfvdCR1I6V0dhaxWURgjnlmwd xMspkYZ9zR0B7hqWoW+lafLe3TFYohkkfXAA+pNUrLWLq51J7OXRby2Cgk3D7fL6ZGDnJJ+lZnxH hjl8Izl2ZdsseMOV/jHvUOoSzad4z0+C1uJ2jOm3DiF52cOy425BJyfel6gdc7FULBCxAztXqfYV Q0HWItd0tNQhikiR3ZdkmNwKsQen0rlvDcsmpjSdZTxEBJIWW5tRuYzE9UKlvlKnuB2rO0bUWg0j w/YPOYLO/wBQuUmkRyucMxVN2QRk00vvEdvpWtx6peaharbyxPp8whk8zHzHGcjBPGK1RXIeDI44 Nc8TwxOzql8v3nLkfIO55q94qOpCOzOmhJ3SRmeyacwtcqF5CsO464qeiHbVl651qK21+z0doJTJ eRu6SjGwBRkg85z+FaeK86he31vVvC22S8SKWC6VvMlKygjIKlgc8HjIPak0jUWubLT9Pnv7mab7 XdxxRNOUEsaZALv975e3UmqtZCOz1bW49IuLGKW3lk+23C26OmMKx6Z5zRYa1FqOqahp628scuns iuz4w24ZBGD7VxFtfS33hjwrNc3BnmGsqhdn3E4dgMnvxiui8PEf8Jp4n5/jt/8A0A0Ws7A9jV1v Wo9Dt4ZpreaVJpkhHl7flZjgE5PT6Vp4wBXLfENd+gWybygbULcFgcEfOO/auf1i9v8AwxqGq29p qN1Lp/lQSSSTyNKbZnk2sQx5AK5OM0txnpVFc34ftTbapdPHrgvbe4jR0t03MsR/vBizdfT8aj8c ySxWOntDdTWzPqMMbNDIVJVmwR7/AI0xHUUV5tqGp3uhw+JYLO6uHit7m2CmSUyNAsn3yCeff2qz 4ge407Uby20+9uPsU+jyzuftDEwupG1w2cjOcdaFqVY9AorgNOlurHWtBaG6ubp7/SHkliluCwlk VVK9SQvXqMUniHV/EN14Sv5tR0mXQJYXi8l475ZGfLAEZXp+NLcR6BUUshjjd9hfaM7V6n6Zrz3X XuNNuvEtpa6heBF0pLtCblyySZILKc5H0HFalvfSP4v0+IXruk2imSSLziVLfLhtucZ680PYa1L8 fjC2l0zTL8WdyItSufs6A7cxtuK/Nz7ds10YrzKzYf8ACGeFeR/yGV7/APTV69LYhVJJxgZzTdkS r6D6K84tNSZ9X0S4h1CZ7W+nuUeSW4O6ZQGxlOigEADv+dQabNcx6bouo/2ndyTtrTWzeZcswaMy MNpXODwO+T70kM7rX9Zj0DSpdRmglmjjYBlixkZOM8kcVpqcgH1ry/W7v+2fCOv3l5dSLdW2oGFY fOKiJFcBV25wcjnpzn2r06PlExyNooB7jZXMcTuEZ9qk7V6n6VS0PV4dd0iHUoYpIo5i2Fk+8MMQ c/lXLLeXln4iRdQ82e2ubqRbS9t7glCSCPKljzxjB56cCsrQhJZaV4XvILycPc6jJBLH5x2MhZ/l 2Zx1Gc4z70dwe6PUO1FecS6lfXPhPUNbW8nj1azvnVYxIdq7XAERTOCCuO3fNS3+oXEK+MxJfTwt DbxSwr57DymKEnbzkc+lMDrpdaii8RQ6K0EolngaZJeNmFIBHXPejVNai0q50+CW3lk+3XAgR1xt RiP4smuYe6kXxHodyrGab+w5XGWyXOEP45NZqzRajp/g/V5L2Wa6uNSTzt0xK7iGyu3OBg8dOKED 0PSmyATgk44AqCyuJLu1WWW1ktnLEGKXGeDgHj161LMoeN1JIypGQcEf4V5za3N1ceHvDBbUrsPP q0kMri4OZE3ScE556D8qFqxM9K9BWbrusR6DpU2pTQSzRw43LFjPJxnkiuKfVrjR49Ssze3AsYda igeaSZneCFwpb5ycgZzyemaueKYLe18Ja+ttqkt1G6o/lPL5ggyeiseecZ5NK5R3StvVWHRhmmyM URmCFyoJ2jqa4i8u5IdW8TQtfTxRR6VFLGPPYCNsPll5+XoOlM0rUpNT1DStMvruUQtoiXKnzypn lOAxLAgsQO2e+aJCR1mhavFrulJqEMUkSSO6hZMbhtYqc/iK0a8v0O+8jSNA0xr5bezuprtWmkc/ O6yHapYMOuSevJFdv4Yt5bXTWt5dV/tPy5mCz7TwuchMkndjpnNN9xG1S1wnjK+P2jVUt72YT2em +bs88xJCcnDDHLOcDg8ADrzXW6PcNdaNZXDyCR5IEZm9SVGaFqh9S9RSCloAKKKKACiiigAooooA hngiuYWhnjWWJxhkcAgj3BqnB4f0a2KNb6TZRGM5TZAo2n2wOKsX9/b6ZZS3l07JBCpaRlQttA6n ABNU28R6WksURuH3zWxuowIXO6MYyRx7jjrQBbm0+yuLmK5ns4ZZ4c+VK8YLR/7pxkfhUdtpGn2c m+2soYW55RAMA8nHpk9fWqNj4t0fU7i2gtbmRmu0L27NC6rIAMkKxABIHUZzSadrNgLO+ujqctxF HdtGxmjKmJ8geWq4BOCQB1JJoAtjQNHESQrpVmI0k81U8hcK/wDeAxwfenNoekOJw+mWhFwczAwq RIfVuOfxqm/izSI0vWkmmiNiivcq9u4aNWzgkYyRwelW01vT21BLETnz3g+0KChAMfHzbiMdx3oA wdT8KTXesSTnTdHv7VkVIkuoyrW6qMbVwCCM5PatW08M6ZDY2lvc2kFybQkwl48+USc4TOSAOgHo KktfEWm3moJYxTsJ5UMkSvGyiRR1KkjDDp0qze6ha6f5SzyMJJmKxxopdnPU4ABPA5o2QEa6DpCR xRrploEhffEPJX5G/vDjg+9Pi0fTop2njsYFkdmZmEYGSep+p7msDwx4haaz1S51C7lmSLUpIIDJ Hh9oxtQKADnrxjNXx4v0XYjm6dd1z9lwYXysvZWGPlP1oAujQNGWJIRpdmI0k8xEEC4V/wC8Bjr7 05tE0t9SGptp1s16vS4MY3jt1xmqet6zZW1hqCTX09mbaMGW4jhZjDu6EcEH9amu9esNNiH2iaRy kHnOUiZyI/75wOBwf1oAWfw3od1cSXNxpNpLNKQZJHhBLkdCfWtJUVFCoAFAwABwKy7nxJpdrbi5 adpImh88tFGz7Y/7xwOB/gavR3tvLZLfRzI1s0fmCUH5duM5z6Yo2QbiW9jaWbySW1rDC8rbpGjQ KXPqcdTUdzpWn3kMkN1YwTRSvvkR4wQzf3iMdeOtQQ69p06ylZXjWOITM8sTIChzhgSBnoelVJvG GiQpdNPcyRG0QSSq8Lhgh6MBjOO2fzoAuHw/opWRDpVmUkKl1MCkMV+7kY7dqlOkaYZnmOn2xllT Y7mEZZfQnHI9qypvEWm30lmsGpXNruuxEm22YCdtpIQll+7g5yOuOtXD4k0tb0WrXDbzP9m3iJtn m4zs3Yxnj1o3Alm8P6NdWcVlNpVpJbQnMcJhXYn0GMD8KvRRRwRrFEioijCqowAPQVg6De3k3iTX 7O4ummitZYxCrADYCgJHA9atX/ibTdOv2sbiWX7SsRm8qOB3YpnGRtBz+HSkFiWXTEXWBqcOFkkj 8m4UjiVO34jJ/A0i+G9CUsRo9iC53MRbryfU8dabF4i0u4ksViuix1CMyW2I2xIAMnBxjp261C/i 3RI7Vbprp1ie5NsGML/63ONp44OfWnsG5p3NhZ3kC29zawzRLgrG6BlGOmBT5beGaIQyRI8YIO1g MDByPywKxG8a6FHHcO89wptX2zqbWTdF7suMhffpWdP4oTS/Ft6t7fTSad9hjuIkjhL7csckbRnG MdelAHQf2asmsjU7jDSRRmK3UdEBPzH6nA/KrNpZ2unwCC0t0giyW2RqFGSck4HvVRvEGmCzhu45 zPFPH5sXkIZC6euAM1Ul8ZaFDFbSfbHkS6jaWHyoXfeF64wDyO46ijbQNzWisLO3uZbmG1ijnn/1 sqRgM/1I6/jUEmhaRLNNNJpdo8twNsztApMg9GOOfxqZr63jsvtry7INgfcwIwD046556Vmv4u0a KK7kmuJI/sSB50eFwyKejbcZIPrQBej0jTI5oZo9Ptklt12QuIlBjX0BxwKszQxXETQzRrLG4wyM Mhh7g9azrTxHpV/dyWsNwyyxxCc+ZGyBoz/ECQAw+lJB4m0qa5FutwUdoTOhljZFeMdWBI5FAIlb w/orWiWbaTZG2Rtyw+QuwH1AxiprXStPspDJaWNvA7DBaOIKT+QqtaeINNvLuOzinZZZk8yISRsn mr6qSBn8KxNf8Sg3ejx6XeTBZtRWGQiI+XMuDuG8jtjsaOtg6HQz6Jpd1fR39xp1tLdxfcnaIFx+ PWrMkEMk0UzxK0kQOxiOVz1wfes+48RaVaXa281wULzeQJNh8sSdk3YwD2+tY3jLxH9i0e5/s28m juoJ442kihLIGLLlWbBA4J9KF0SBnRvpWnS3q30ljbvdKu0TNEC4HoGxnFQDw3oYZ2/sexDSHcx+ zr8x9Tx1q3cXkFlYPd3Ugjhij3u57Cs+LxPpUouD9oeM2qq8qyRsrBW+6cEcg9sUAayosahVUKoG AAOlVdQ0yw1aAW+oWcN1EDuCTIGGfUZpLPUYL4yrD5ivCwWRZI2UqSMjggdqxb7xL519rOk2ouIL ixtDKs4iON5UkYyCMcd+tLpce7sbFzoul3tiljc6fbzWseNkLxgquOmB2pTo2mH7NnTrU/ZP+PfM I/df7vHH4Vi+FvE9tf6fplrcXEj6hcWglLPEVEpH3trY2kj0BrRj8SaXJfQWYuG8y43CFmRgkpHU K2ME/SmSmW5dMsJro3UtnBJcGMxmVowWKnqufT2qM6DpBt4bY6VZmGBt0UfkLtjPqBjip7u7hsre S4uZBHGnVj+X+RVe01rT7pZ9k5Q2yhplnRojGMZyQwBxQMmXTLBLmS6jsrdZ5V2SSiMbnX0JxyKh ttA0ezgnt7XS7WGK4H76NIgFk9iMc03T9f03Urgw2s7mTbvVZImTev8AeXcBuHuKY/iPSYZnha6x Kj7Gj2MWB9cYzj36UATQaFpFowa2021hYRmLKQqDsPVenT2psvh7RZrCPT5NKtHtI23JAYV2KfUD HFMvdT8nUrK0S4RGlf5leNj5i46K2MZ79as3uo2+norTeYS52qsUTSMx9goJoAnhhit4khhjWONB hVUYAHoKq32jabqEqzXljDNIowHZMtj0z6e1SJcG/sPO06eMGRf3cjoWUH3GQfw4qjbaley+F/7R aOGS6ETuV5RGKk/UgHHvQwXkXZ9NsrizWzmtYmt1xti2jauOmPSoU0DR0jaIaXaBGILL5K4JHTPq RVC31+5vLfTJ4bSJVu3EdwkkhDwvjJGAOavnXNPFr9qM5EPm+SW8tuHzjB445oAktdKsNPeR7Kzh geQYYogGap21jqUmqpfajNbnyEZYY4Fb+LqxJPPHaln8TaRa3UtrPd7Jom2upjY4J6DOOp7Dv2qC bxFDBfWknnxmxuom8sCJvNLg9AOpP+zjNLsHQu3egaTfXJurvTbeaY4y7xgk46Z9cVPd6VYX6xi7 tIpvL+5uT7v0qL+2dPOmtfm6VbZDhnbKlW/ukdQ3tjNLY6xY6mkrW8j7oceZHJE0cidxlWAIz9KY Ep06zax+wm1h+zbdvk7Btx9KSx0ux0xWWytIoN5yxRcFvqe9VoPEelXM0UUN35kkp2hQjZU+jcfL +OKs3+o2ul232i7l2R7ggOCSWPAA9TmgB15p9pqMXk3trDcxA7gkyB1z64Pem/2Zp4uYrr7FbieF dkUvljcg9AcZArG1Lxnp9lpxu4VmnZbtbSSIRMGjkJH3hjI6/j2qT/hLLQ65eaa0NyiWlss7yeQ/ fPQAccCjpcDRt9C0m2u5bu3062huJgRLIkQBYHqM4pG0DR2sTp7aXaG0Lb/I8kbN3rjHWsa78XaN faU81vqtzaxfu2F1HbN0ZsDBK4IJ4qCbxSuj+LdXg1O8maygghkiRYC5i3Z3H5RnHHU0AdJZaTp+ nM7WNlBbGTG8xIFLY9SOtOu9Os74obq3jmMZJQsuSh6Eg9qqxeIdKnn8iG68x/s32obI2IaL+8Dj B+g5qjN4w0/z9IW1Wa4h1UuY5UhfACg54xnOR0o6gax0jTfMhl/s628y3UrE/lDMYPUA44/Cof8A hHdFKIv9k2e2OTzVXyFADn+IcdaZP4l0q2u47eW4Kl5fIV/LPl+Z/d3Yxn8adr+sLomkSXpTc+5Y 4k/vOxwo/OgB40HRxGkY0u02Ryeai+SuFc/xDjg+9TQ6fZW1zLdW9nBHcTf6yVIwrP8A7xA5rm/E V5qmn3/h+1h1SSL7dd+TclUQ8bSxxlTjkflTvD2r3+oanrenSXP2q2smAt7+NAMkjJU8bSR6gUr6 Nh5HS3Nnb3tu1vdQRzwv95JFDA/nUcOmWMNs9tHZwpDIDvjCDDfX1rjvDmr32saNBLN4lMeoyXDx JDsiIba5GCoXPQda1dP1S88R6zqcdrdvZ2OnTfZw0SqXmkxliSwOAOnAz71VrOwjb07SdO0mEw6f ZQ2kbHJWFAoJ/Cn3dhZ34VL20huRGwdBLGGCn1GehqvpsGpQy3Ud9dC5i3L9ncoFbGOd2O+a53xZ r1xaazBp41K40W3YDN6bLzYpHJ4UseF//VU72GdOuk6erzyJYWwe5G2dvKAMo/2uOfxpkeiaXHbS WyadbiCVdskflja6+hHp7Vn6zZ65LbM9jrn2FbeDcJBAknnMBkls8AcdBjr1rJm8UX0OhaBqOpF9 PgveL25jUEQnB2nnICk98d6YHUR6PpkU0E0en2yS267YXWJQ0Y9FOOBUt5Y2uoQeRe20VzCSCY5U DrkdDg1ysniLUotMso9+Z9T1L7LaXLIAWhPPmEYxnAOOMHg1paRqlx/wkWpaHdzNO9qkc0UxADNG +eDjAyCPTvQBqDSNN857j+z7bzZI/Ld/KG5k/uk45HtUNv4e0W0KG30q0iMalVKwgbQeoHpUV/q0 unamsd0kUVi8RKXDSfxjnaRjj2qnea3qNr4cgv7lbXT5pp403TEukaM2MtyvODnGaXQDUGhaOIIr caVZ+TC++OPyVwjeoGOD71fwMY7VkWN7cXGkyXMN3Z6nMu7y2tl8tGPYfebn8aZaXmowambHUpre 43W5nD28Rj8vBAKnLHOc8HjoaYLUsDw9oiPvXSbMN5hlyIVzv7t0604aBo4iSIaVZiON/MRRAuFb +8Bjg+9ZNprOqvLZ3tx9mOn385ijiSNhJECSEYtn5s4GRgYz7VPdaxqpuL3+zbK3uFsmCtFJMUkm bAPyjBx14Pf2otYV0Xbnw5ot5cSXNzpVpNNKAHd4gS2OmeK0Y40ijWONQiKMBQMACs681uy04Qrd tIs0q7hDFE0j47naoJwPXGKfNrGnxabHqJulNpJgrMgLLj146UDFXR9NjmaaOxgV3JZisY5J6n6n 1pq6Do6xQxLpVmscDb4lEC4jb1AxwfeltdXsL0zfZ7gSCEZYqpwR6qf4h7im6PfG/glmM6TKJ2Vd iFSo4wpB5yO/1o2AkOj6c16bw2UBuCwYy+WNxI6HPr70260PSr66N1d6dbTzmPyzJJGGbb6ZI6c0 ia1Yy3otFlcSFiqlomCsw6hWIwTwe9Mu7i+t9Xso1kha0uXZGjMR8wEIWyGzjHHpQBNHpGmRywzx 6fbJLAu2JxEoaMegOOKgHhrQhOZ/7IsxK0nm7vJGd/r060y81may1+10+W3T7NcxkrOH5RwQACMd CSAKSy1qQh11JIoJDdm2i8tmcM3GMnAxmhAazIroUZQykYIIyCPeqK6Do6xxRjSrMJC/mRqIFAR/ UDHB96bc+INMtVuDcXPli1ZVlLRt8hb7p6dODz0qOHxDp99L9nsrndOwbaHiYYYDocgc45xnOKTd lcOtiyNG0sLcJ/Z1ttuv9ePJH73/AHuOaYmhaTHp39nLptqLMnJt/KGwn1Ix1qhpXia0uYII7q5Q XLMY3ZI2EW/ONu7kAn+6Tmrd74h0vTro29zcMHUAybImcRg9C5UYX8cUxJ3JZ9C0m6lSW4022lki Ty0ZogSq+g9qbL4f0a4gggm0u1eK2/1KGIYj+npUl3q1jYLC11crEk3EbsDtP49Kz7/V1bRZ9X0u Uyi0Bd42Ur5ijkjkA8joaBlxvD2ivYGxbSrQ2hbd5JhG3d64x1q5bW1vZW6W9tCkMKDCIi4Ciks7 uK+sobyBt0U8ayIfUEZFYHjXUNQ02zsJdPvDbtLfRQP8isCrtg9QcUdQ6GxdaNpl7ci4u9Ptp5gm wSSxBjtPUZNWba2htIEgtoUhijGEjRcBR6VkXfizR9OnuLW4uJmntI1edVt3dgp/i4HTg89K2Lee K6top4ZBJFKgdHHRgRkGgCWiiigAooooAKKKKACiiigDM16zl1DQdQs4cebcWzxpk4GSpA/nXJ21 prUl7o9xJolxElppsttKGlj3byFA43YwSODnPsK76qr39nFexWUlzGtzMCY4iw3MB1IFKw7nG6do +r21r4Rjl02QHTWf7T+8Q7MoVH8XPJHTNQyaJrqWd1cQ6c5mh1038Vu0qA3EfTAIJAPfBx0r0Kim 9Xcm2ljz2aC917UvFdutm9tc3WmQIkMrLuBIfAYqSAfxqU6ZrGq6lC8mlz2UTaNLZNJJIhKSNjBI BPHB9/YV10OkWUGpz6lHG63VwoWRzIxDAdBjOOMntV8UrDvqcf4YtL3zLSPUPDFvZXNkhR7zKNv4 x+7I5GepzjjjmrPiC01GLxFpOtWNo99DarJFPbxsA4D4w65IBII5GeldPS1Td3cSVkecPouum2ur tdH3yxa019HaTSJ+/iZSpGckBhnPNbUmhnWfDd/CNHi0ae5w8SAKJBIuCrMV4zuA7nj8q6wmip6W H1OR1DS9WuvAF9BJa+dq9/DmWNGAG84GMkgYAA71F5Gt6V4he/h0d7+11CziiljWVA0EiAjBycFS D1Ga6WDV9Pubx7OC8hkuEXc0auC2M4zj0zxmr1PrcOljiL7TtTs/ELXr+H4tXtb61jikijKDyHXP GHx8pB/TpXTLbNDoJtksoNwtygtYgBH0+4PQdq0aqvf2iXsdi11Gt1IpZISw3MB1OOuKN1YOtzhh 4X1iTTdQ07T/ALRBYy2ymG1v5A/kzK4YIjAk7MD1xzUl7p+o6t4b1FYvCUen30lr5Aw8ZeQ5GQrA j5OD1PfpXb3V7bWSxtczpEJZBGhY43MegHuasUAtDldbsb+7g8P+RYyMbW7jlnXegMahCDnJ5OT2 zWPqGmeILy5V30mVpLfWFnVkmRYmhBOCq5+9zkkjP8q7ee/s7a5gtprmOOe4JEMbMA0hHJwO/FWu tKwjndFsr238T65dXFo8UF28bQyFlIYBADwDkc+1R3dlfnxwNQjsZJLVdNaDzFZOXLZxgnPT2xXT 0lD1sM8/sNH1nTtP8LTPpUskumPMlxAkiFwHGAwOcHp61Gui62dLEL6VJ5v9vfbCBLGR5W4nd1Hr 0r0WkwKdxdLHE32k6rPdeLGj06QrqVskdsd6DeRHtP8AFxz64p+n2WqaXrEd8+kzTpJpUNsUR0yk ik5Vsnpz1GRXaVUuNU0+zlEV1fW8EhGQkkgU4+hpdCjhYfDWqeHm0qdNKTWYkt3hubZGUNGWcuCu 4gEDOK1Y9KvI9e0G4g0aO1tbaOfzkt2QJAXxgYyMnjkgV1MFzDcx+ZbzJKmSAyEEHHXkU6KaKZN0 UiuuSMqcjI68076kmT4s0y61bw3c2lnsNxlXjVz8rlWDbT7HGK5+8sL/AFXw1qnk+E49Pvp7XyAo aPzJWzyAwP3R7n8K7uigq5w9/omqalqkY+xyW8T6I9k0xdMJI3sDnHvilWx1zXPC0ui3mlDTrhbN rc3TyKyswGBswc4OOc4/Gu3oo8hdbnFtpOpa2dD+02cmnSaYj+a7Mpy5j2AJg8jv27VnW+n6+mi6 HpMuiytJpF9G0k6yp5csa7vnXnOTnOCK9DzS5o6iOG03Sb6yvJtNvPDkF7E1408GoSFCgUtuy4Pz Bh0HvVG50jXoPDureH10ma7aW8NxBdJIgSVDIG5yQQwwe3416OTRmhaDZla2uoP4auV0+BHvjCBH FLggtxwc8evtXJpoupSahqM1zoFzPbX2nwxNFLcpvZlb5gTu4PcYOOO1d/I6xRs8jBUUZJY4wPXN RWl5bahbJc2k6TwODtdDlT+NAGJ4W0/UtPF5DczXE1kHX7GbshpguOQxHUA8DPNVLvTNTj8Q67PH YPNBqFgscUiSKMOqkbSCQc5P0rrqr3d5bWFs9zdzxwQxjLSSNhV/Gkxo4y00XVgPC8clhJELG1lh umEifuiyBQeDz+Gaf4a0y/tPsen6h4at1lsHONSOxlcDOGQfeDH3967VJFkjWSNgyuAQR3B707NM nyMzX45JdNMaWL3oaRd8SSBGC55ZTkcjjvWHNpOo6rpmp2ai6hiniVYTeMpl3Bt2AwydvGPmzya7 GigZyGl2M0mrWk09nrKvbBvmu54zHGSMEDBy2auWBuo/Ed/cSaDcxrdtGguSYiAqrjnDbsZ9q6Kq 6XtrLey2aTobmJQ7xA/MoPQke9AGTrc1813Zrb6Pd3KW9wsrSxvEARg9AzA9/Sk1f7fPPbMba/8A sjREtFaSKsgkzwGbPTHoevWrU3iLRre6FtLqdtHMW2hGkGSc4wPXmtagDnPD41DTNDkW40q6Myzu yxecjs4Y5B3FsfmRTNN/tBfDNxYy6PcwzpA4RXePEhbOACHPr3xXS1FLLHbxPNK6pGilnZugA6k0 MEc1DpmoLfaVcR2jxRNtN5FI67onRcBuCQc9ODUeoRamllqWn2+jz3L3F2ZlkDoqFCynqSDnjpiu oguYbqBJ4JFkikUMjqchgehqajqBy81pfSajcTjTZdn2+CVSWT51UYYjnt781Vjt9UtNTs5/7Fml itXnLOHTdhzwVG7n3ziuypKXYHqcfqWj6hqdtNfJbTW8hvY7hbVJFWRlQYPPQMc569qt6JaSR6jP ftZasZFg8sNeyxkvznaoB/U101FMDnvDi3NubmOfRZ7MzTvM0rtEQ2emdrE5/CpPFEepSaZF/Zts bhxcIZkUqH8vPzFN3G73rdpaAPNpvD+tm01dY9Ll/eapDeQo06M0sa43DJJ5GO5ramsdUXxLqd6u myPDqGmpEhWRAUcZ+Vsnrz2yPeutJopW0sCdmcLPourP8MLTSF06T7dGIleDemRtcE85x0HrV2W0 1G38T6pejTJLiK/so44yjJ8rgHKtk8dfcV11VYtQs5ryaziuY3uIAGliVgWQHpkdqA2OMsfD+qeH r3TfKsnvkTS3s3aJ1AjkLbv4iPl7cU3StG1qzsfCzy6XIZNNlmW4iWVMqHzhgc4I5+vtXf0UxWOE 0vR7+zuZtLvfDdvep9raaHUX2Mm1m3fMD825T6fpWp49tJrrw8ksClzZ3cNyy+qqwLfpXT00gMCC AQRgg85oGcp4r0651nUdAlttPN7Z2915853IF2FSOjEZ60ui6fqnhu4utJhsZLrRmzLZyI6BoM9Y iCRkZ6EV08EMVvGIYlCqOQuelS0mtLAmcn4H0SWw0KKHVNMFvdwXEkilijH5mJBBBPY03TrHUPC+ t6n5Ony32nalP9pRoGXfC5+8rKxGR3yPyrrFdHBKsGGccHNPpt3ElYqWklzMrSTQmAMfljY5YfXH H5Vk6y93qUV9or6JI8E0exbl3TyiCOSedwx9K6GigZymrf2rbw2mk2ui3Wo2MUKrNNHPGhkwAAvz MDjjn8qW+t9R1JNKlu9K2Was/wBq03erkAjCZ/hOOuK6mqN9q+naaR9uvILct08x9vXpS06jOSi8 JXlrplqbeN9um6p9rsrWSTLJDjBjyTgdWwM4HFbWjaXP/wAJHqeu3cJha7SOGGJiNyxrnJOOOSf0 rZtbu3vrVLm1mWaCQZV1OQwps2oWlvdQWs1zHHPcEiKNmAZ8dcDvT6k9DJ1uxuNbvF02e1mTTkTz TOrr88o5UDncMHn/AOtU0F9qn9jxTXmjSSXKPtlhDpuYDo6849DjOa0Ly/tNNtzcXtzHBFkLvkYA ZPQVaHIoGc7bDUok1TVYNLdZbgL9ns2dVZioI3Mc4Gc+vQUuiLdZmW80y7hmuFLz3c7R/M3QKoVm IAGcDt9TXQ0Uug9TkrK01Nzp2kzWEkUWn3HmPcllKSIpOzbg5yeM5HHNLqkV1dzXaXHh2R7veUsr 22dVOzAwxfcGXBzXWUU7kpWOP1LSdQg1caizahOJrWOKRrCRVZXTOSQ2Mg57elSSadcQ+C7jT4NJ vJnuQ4MEssbP8xySxyF59ia6yilcZQtbmX+zy/8AZc9u0QwlsTHuIHQDDFf1rP0WXUBNepPpFzae fO80ckrxleVAAO1ic8elb9FMDiTa6s9zYTNp+pTXENysl073CCMeuxdwBHpwOPetfV57/wDtayaD Rbu5itZWdpI3iAYFCONzg9T3Fa817bQ3UFtLOiTXBIiQnl8DJx+FWKAMDULaa+1aJZNPm+zS2bxy S7k/dMzKwzznIx1FVYbHVY9Dc3VsZLpL9Z2RGGZFVl5HpkDOK6aaWOCJ5ZXCRoCzMx4AHc0kE8N1 bx3EEiyRSqGR1PBB6EUAcpeLqt7Nfzf2FcBJhbiJTLFuYI5LZG7g81Ya1vor5p10+WRU1FphsZMs jQ7cjJHf8a6OWWOGNpJXVEUZLMcACq9lqVnqSu9ncx3Co21zG2dp9KVgOasrfUjoH9iTaK9vJK7H zN6GNFLlt2Qc7hnp696iutIvLXVNRYx6tPDey+ajWMyBTlQpVgxHTH0rth0opgcvf2U8Wj6TYw6N Pdx27xO8fmRt5YTGASzDJ+npV3XLpv8AhFL+aW3khd7d1ELlS+4jCjgkZJPrW3UUsEUzo0iByjbl z2NG4LQxfDkF5pen6Zo8tmxjhsVElyGG1XGBsx19fyqv42sb/UbLT47Cye5aG+ink2ui7VU5P3iK 3rm8tbIxC5nSIzSCOPecb2PRR6mrNO+okrHIXOn6lLr2uXS6dIYrvTUghbenzON2R97/AGhWx4bt 7mz8Nafa3ULQTwW6RyIWBwQoB5GRWvRS6WGA6CloooAKKKKACiiigAooooAyfEs9xbeGtRuLSYQz xWzujlc4IBPT8K5M/wBoy6j4NYXED3b20xErxnaoMa8kZyT+Iz7V3F/aR39hPZzZ8ueNo32nBwRg 4/Ose28Kww3Glzf2jeySaUjJDuKYYEYO75fQAcY6ULcH0Myx8WaldwWln5UTahNcXELvGny4hOCy qWHJyOM8c1v6Dcatcaex1mzW2uUlZQFIIkUHhgATjI7ZrKk8CWTWqxxahfRTxXT3UN0jqHidzlgM AAg+hBrc06x/s+38r7RNcuTueaY5dz6nAA9OABQttQe5j/2tq+py6idHW1/0C6Fv5U4OZcbS53A/ LwTjg9Kq6l4n1LT9RRT9maI6hHamFFZyEfA3M4OFbJzgjpV6XwlbnWLjUYL+9tlvCpurWJwI5mHG TkZGRwcEZqCbwPaStMBqV9FFLei9WJGTakoOcjKk49iSKED8hqeJpz4ofSbiSKzkWYhIJomBniAP zRvnBOcZGOBn603T9e17VHsb+z09ZdOupisgO0GOPJw4bfkkY5GO/HStF/DUM1zFJdXdxcxw3JuY opNp2Pz0bGccnjP6VBp/hC30u+eS21C9Fk0pmWwMgMKOTnI4zjPOM4zQugFnxHrB0e2tvLUNPeXS W0RbOFZu59cAHis2XWdTTU9T0Od4fPjsvtVtcpEwUryCGXPUEdQe/StrWdFttcsfsl0zqFdZY5Iz ho3U5VlPqKrpoCBrqWe7nlu7mEQNckLuVBnAUYwOpPTqal3aHexR8DWxbwjpVxciGSb7KoSRYtrK pGSpOTnnr0BqvqnifUtO1AD/AEZ4v7QjtjCis5Eb4G5nBwrZOcEdK6DR9Kj0bSrfTYZpZYrdNiNL jdjsDgAfpWNP4HtLh7j/AImV9HFPeLe+UjJtSUHORlScH0JIq3rK/QhK0bdS94tuLq08K6ncWc3k zRW7usm3cRgdvf37Vzsq6jJ4g8MFJ4Ptj2E5854iVAwnO3OSfxHrXZahYw6jplxp9wWMVxEY3IOD gjHX1rLh8Lxw3mn3R1K9kl0+FoYy5TDKwGcgL14HTHSktynsZC+KdRm0DS72SG1aWXUxZ3A8skcO V3Jzx07561N/b+sjVdZDyWSWGjyBpQIm8ySMx7uDnAb+ftVlfBVqunQWI1C98uC9+2qSU3eZuLY+ 70yTV628O21vd6lcSTzzjU8efFLt2/d24GAD0460tbPuPr5HM3t5fX+peENTungENxcNKI0Q5jzE xHzZOePYc1bvviHpt1ompXXh27S6urCMSOk0EirjdjuBVu28Ew2z6eo1fUHh02XzLSJimIxgjbnb kjBxyan8cQSz+DtSt7aCSWaaPaiQxlmJyOwFU7fISvdXKS+INdstbSx1COymS8snuLVogyBHQAlW JJ45HzcVHZ+KNTlv57JmtpW/s03iSrCyoGBIK8n5l9wa0E8OW+o2okv5rm4eay+zKZMI0aMPmwAB hunJ9KZB4NghnjnbVb+WWOzNnuYpzHzgYC4yP/11PkGm5gX2s+Jrvwpp+qPd2Vut7NbAJDC2Ruf5 gSW6dOn0zW5Nr1/pfiGax1SS2Fq9mZ7WWOJlLuv31OWPPTAHXNWH8J2r+GrfQvtd15VqUMM2V8xS hBU9MHp3FVr+zXXdVs9Om0+7K6XOs7Xs6hVfC9FIPJJIzxjinpdrz/QSv17G5YyXp0qKa8EZujHu dY1IXOMgAEk/rXOfDf8A0zw2+q3GJL29uZXuJGHzZDkBfbAAAFdh6VhReGUsL24n0u/ubCO5cyTQ RhGjLnqwDA7Sfbj2pdR9Bb8weHNDuPsMRjaWU+VGik/vJD2UDtknA9KwvBE6aVrWpeGg8zQZ+2Wb TxsjMrffGGAJw3866VtFR7mzn+2XI+yMzhMqRKx/ibI6/TFR6j4ch1LWrHV2vLmC4sQwQRFQrA9Q 2QSRQtGD1Qmu6xJpk2nWdvs+06jc+TG0gJVBgliefbgZ71hap4t1fS4tctmjtpL3S0imjfYwjljc 4GRnIYc98V0es6Jb61BBHNJJDJbyiaCeIgPG46EZBHqCD1qleeErW/sr63ubu4M2oBRcXC7Q7KvQ DjAH4U0DNHSv7SNuW1KW3kdjuj8hCoCkdDknmue1HxPqVhqSK32Z4W1FbUwxozERt0ZnzgN3246V 1dvGYYI49zPsULubGTjvxXOTeB7SYygalfRxtei9WJWXakuckj5ckH0JNLr5B0Zr67e3Nho9zdWd u9zNCAREq5J5GSBwTgZOO+K5DUvEV5qWj21zpur20kcmpwQFkgZW2nqrqTlSCPxrtNQs/tlm8AuJ bcnBEsRG8EEEYyD6dxWRceDrO7juDJczpcXFxHcvcRhQ29BhSBjH6UdQ6FHXvEmp6PLcvutXW3lh XyljZy6uQGLEH92cngH9aTUvEGux6hrsFm1ikel2yXMZkiZi4Klip+YenX9KtXfge1vPt6nUr6OO /dJZkVlI8xcYcZGew4zj2q0/hO2kn1KZ7+8LalbrbzcpwoGBj5eDg0+nmCtfyKsPiC71e8SxsfJt 3XT47uZpULjLj5VAyPxNY/hm/vbHwho8cElvF5qzeYxjLsWDHASMHJBOcntW6PB0EVzaXVpqN5a3 Ftbi1aVChM0Y6BgRjj1xmorXwPa2S2PkalfI9ksiI4KZdHOWU/L69+vvR3AzrbxVrupRaCtmtlDJ qsMpcyxswRk6EYYcH07VH4g1XUdY8MeJIYntkTTo2t5gYyfNcKC5HPyjnjrWxp/gu002bTXi1C9Y aaX8lXKEEP1B+XNJfeCra7n1GSHULy0i1RcXcEJXbIcY3cg4PuKHuC0KEviWfS3sLF5IrKOW1g+z T3MTNFOxA3KWBAUgdM10muaoui6Jdak6bxAmQuepJAHP1IqjceE4bm0eymv7mS0kiSKSFwpDBMYI 44PHOK077TrXUdMl024i3200flumf4cfzoewkrGNeatrOj2lzqOoLa3FlHarKhiyjCQkDbjJyvI5 qtNrHii1hvp5rKAW8dk1xFcMoAWRRkoVDkkH14q7aeEre30+axvr+71OCSHyALpwfLjPYYA56c9e Kba+EFg06exm1jUbpJITAjTOpMKEYIXjrjjJyaXTQfXUxdR1HxJNp2iXkl5ZwJf3kGEhhbOGUkhi W5GfTFa8ep6hJ4i1nTP9GU21pHJFOsR3ZYHO7nkDHHSrN14Yt7jRbHS2vLlRYOjwTqV3gp07Y/Sp I/D0SareakL66M17AsD52YUKOCPl680PVWFs7nIaZd3em+A9E1Bo7K6ka5SJWltyWRXkIYhtx596 6NNW1jVHu5dJW1Mdnem2MUwOZApAc5zx7cUp8GWv/CP2ui/b7z7PaTLLGwKb8qcgH5cYz7U7/hEo I9XuL631C9giu3ElzaxuPLmcfxdMjPfB5p3u2w6FDVfFGo6bqA4tpIRqEdt5KKzN5b/xM4OFbvtx 0qK31DWBe+LpTdW8y2JHkxSQnaMR7gOG6evrV658D2dw06jUb6KKa7F4IkZdqSg5yPlz+BOKtv4Y tzc6nNHeXUY1SPbOildoO3buGQTnH4e1Lp5j0v5FHT/EV5qM2l6dbeRBc3GnC8ldkLKgPAVVz6+/ SqSeMNYuItPjjgtYrl9UbT7oOrFcqD8y88Z4OOa14/CVtAdOktby5iudOh+zx3Hylnj/ALrjGD+V K/hCyxYhLi5jNndG7DIVzLKerNkHP4YpsEO8N6tfX8up2mo+S0+n3Rh82FCiyLgEHBJx19aoeKPE epaKb2W3a22WsKSRxlGkeTJ+bfg/IPQnvWzpehxaVeX91HczytfzedIJNuFbGOMAVQ1TwZa6pdaj M99eQLqUSx3EUTLtbb0IyCR+BxQwK+peJb2O9ura3ENsINN+2o86lvOP90cjp049ahg8Sa3fxQ2t rbRrftYLdSDy8hS33V2swOPU1S1XT549eVZJNahS3t44ra4toEnWXHXcCpCtn2Ga0/8AhFrnUVs9 RudUvLPVYVMZuINiPJGTkLIuCpP8qQDBrfiOXV9O01rezsJ7uxeeZJFMhhkU4x8rYYH6j603SvFd 7qtvpFsFhhv75ZjK+wlEEZIJAz3PbNao8M26apbagl5dJJa27W6LuUgqxyScgknPvVE+A7MadZ20 GoX0M9jK8tvdqy+Ym45YdMEHPTFMBt1rPiDSTpkuqJYpbTXRt7t41Y7ATiNwc8Z7g9K2tJu7m+W4 nkMZtzMy2xRCCUHGSc8859KxtasgdL/4RkWN7fm/Q77txlFORlnbI2nvgCr8+k3EdzpK2N1cQQWX yyxqw8uVAMYYdSfSmDKnj26vbPw1JLY3P2eQzRozbM5BYDA9Kx7uTVLTxfrtxZTWq3MGlxSO8kJK tgscbQe+OuTXXa3pEGuaXJp9y0kaOQQ8ZG5SDkEZGO3pVD/hFIWu726k1G9klvbUW0pYp90dx8vX k0tdQ6rsUF8T6jqiW0GmW6/apdOS8clQwBbouCw4z3zXQaTPfXOl282pWotLxkzNCGDBG7gEdfWs aTwRbbdPa11O/tLmwh+zpcxMoeSP+6wxg/lXQ2lslnbR28bMyoMbnOSfUk09BanP3uvahb6jNEGt YFjlCRQ3Mbr54OPmEudo78YPSr0t9fG61S3j8kNbRLJbsynHIJw3r07VHL4defzoW1a8NpPJ5jwE IR1ztBIyF/yMVLqGim7uXlh1C4tPOj8uZYQvzqOmMg4PPUVPQrqZdxNdXOp6LeWcFul5dW775XBK xjbnnoWGegyK04LvVJ4rq0/0aO/tWXLlWaN1PIOM5GQDxnj3qu3hcD7AY9Uvo3sIjHCwKHg8EsNv zccVbihXRbaadjc308jgyuFBdz0HAwMD0FBKKGnX39k6Zqz3cUCmxleST7MGAfIBzg5waqaZ4suJ 7+zjnmtZ0vG2+VbxOHtyRxlicMPU4GK09KtZLuDUZb20eGO+lJEMuN2zaBzg8Z5qSz0O5tZoc6ze S28GNkDLHyB0DMFycfUe+aY3+pC19rV5HPdaXHatDFIyRwyht0204J3ZwvOex6VDqMmtt4ls47K4 too3tWZo5kZhuBGehH4VcfQ3E0v2XVLq1glfe8EW3AY9dpIyue/6YqW+0lriWCa3vZrW4t1KrIoD ZU9QQwOfX60LoD2ZoReZ5aeaVMm0bivQnviuMtI7ufxX4oE8lrNGkUJEctuWBwrFf4ux6+vtXX2s ElvAsclxLcso5klxub64AH6Vmw+Ho4dR1K9W+ut+pIFlUldq4BA2/L2BPWlqGhiad4nv73TNGhgt 4UvL+2knfy4/kjCnHClh3I71FcT6pdan4Vk1myW1vRfTK6qQQQI2wRgnGRzjNaEngizGm6daQahf W8+mZ+zXcbqJVB6g8YI/CrjeGIHm06dr67MunytKrllJlZhgluOePTFPrcXQ5jxTqt3rvg7VbuB4 Y7KC8FusbIS7hHALZzwc57dB712uraimkaNdajKu9LaIyFRxnArDuvAlpcRX1vFqN7bWd/L50trG UKCTOSy5UkZI6ZxXQ3NlFeac9jdAzxSx+XJu/jGMHOO9LoPqY5vvEUVu12y6fLbyWXnKSxj8uXgh SSTlcHrx0rMTxVqgbV4AYJpLPT0vIZPIZFJOcqQTyOOCO3rV6HwTbDSZtLutT1C7tmiMMIlkXMC/ 7OB1Hqc07/hDIGluJpdWvpJbqzFpM7MnKDODgLjPJ9vamBBpWv6vLq+kQXxtXh1WxNwoiRlMTBVP Uk7gc+grU1nVZLO807T7fatxqErIkjglUCqWJx3OBgCo7fwvBb32mXYvbp20yAwQqxXDKQAd3y8n AFTa7oFtr9vCss01tNbSiaC4gO14nHcZ/lSEZ8+s6xYyWen3yWgvr68aGGWMMU8oDdvK5yGxkYzW bqfi3V9NttagMVs95pbxMjlCEmjkOBxnII57mtqfwrb3NnBHNe3Ul3BOJ471mHmrIO/TGMcYxim3 nhG0v7K9t7i6uTJfMhnuFKh22/dA4wAPp3o6jM291rW4Z9b06ae2EsGnfa7eaKIjZnIKkEnOMdf0 ottV1a10LSN11bM01l5ryGFmkYhAQAgOT3yf5Vry+GLafU7q+murmR7qz+ySISuzZ7YHWqkfg2CJ rJk1S/8AMsrdrZXLJmSI/wAJ+XHYcjBpvyBWKmn+Jb3UZfC8rwWyrqscplGw7kZUJ+U54HHSqsXi rXRaC/m+wmCLVjYyxJEwZl3hQwO7jrnoa2LLwZa6f/ZQi1C9I0rf5AZlOQwwQfl9Kb/whVp/Z8li dQvPLe9+2sQU3eZu3f3emRRoCua+szzWujXdxbiMyxQs6iRcqSB0IrnIvEGr3E/h+2tRZQjVLBpm LRMRGwVTwAenPT2611F9ZrfWE1nJI6LMhjZ0IBweuO36Vk2/hS3trnS50vrstpdubeEHZhlIA+b5 euAOmKTuHQ5vWNX1LWPAsFxJJBDONSS3nKRnDlZguV54HHI5rbjvr2bWNT0/TPscNxYxJJcStAcT SsDjgMMAAepNPfwXanR/7K/tG9EP2o3W4GPdv3b/AO70zVqfw9G+qtqVveT2tzND5M7R7SJlHQkE H5hzzTEYUHi3WNXbRF02O1t/7UgmZxcIz+VJGcHGCMjOf8aZd+JvEdvYa3c7tOLaNOqsoifEy7VJ x83y9T61vxeFbK3vdMuLeaeEaZG0cMSldhDfe3ZGST161DP4Otbi21a3e/vNmrSCSfBQEHAGF+Xg YAHNA9SGPW9Xi1640+5FpKH083tvtBj2EHGxiTyOR83H0qpa+I9TuryfTzLbs7aWbuOdIWCq4OCB k4ZfQ+1al34Ttby7e4uLy7cyWJsmXcoBjPU8DrnmmWXhCC0vYbp9Rvbh4rQ2eJCoDR9gdqjpQ9bg nYx9M1jVbfw54Xnnkt7o6hcRRSNJEdyhgTkHP3uP1q1deKNRfStX1ixW3Nvpdw8bQyKS0ix43ncD weuOO1XYvBttFp+nWI1G+MWmzrNASUyMfdU/L0GfrUknhK0aW+EdzPDa6i/mXdqhGx27kEjK5xzj rQ9WCVkZc/iPWrm91GLTns4oLfT472FpoWZiGBO0gN7df0rptG1A6notlfsgRrmBJCo6AsoOKoSe FrZ769ulurmM3tqLV0TbtRBnG0bcjqav6XpyaVplvYRSySx28YRGkxuIAwM4AFAdS8KWkHQUtABR RRQAUUUUAFFFFAEMztHE7qjSMqkhFxlvYVHbTyXFpHNJbvA7oGaFyNyH0ODjP41BrOf7GvSJHjYQ OQ6MVKkAkEEdK5DSNSmvpvDGmX11KtvcaX55cylWuJQAMFgcnAJOM859qFroD0Os0TWY9cs5LmGC WERTvCyS43BkJB6EjqK0hxXlukXos4rTTTfeRZ3OqXiPNI5+Z1b5FZwQeck9eSK0biC5tG0Sz/4S C4vFfVHiaSKRl/dlGPlk5O7HTOc/iKXRB/wfwO9nnit4zJNIsaLjLMcDk4H61F9ol/tEWv2WUxmP f9pyNmc429c579K841NS2gavZy3M8sNjrkUcPmXDMyIWjOCxOTjJxknFdIhZfH4sUu7hrV9JLGPz 2I3b8bgc8HHen28wNK219b2+SO1sbme2eV4ftSAFFdCQ24ZyBkEZx1rTu5pLa1lmjge4dEJESY3O R2GeM1wGi6RNdeA7xtLu7qK8ju55Itl0+GKSsdpAPRhwfXOatXOpvrnhXVfEFtcXVtEtgUgVZWTb IoJZuD13fLn/AGaT2v2HbW3nY7mF2khR2jaNmUEq2Mr7GpK4RUkv/EulWs1/diC50YySpHcsoZgV G7g5B56jFVNP1W9fQPDUl1eyS273Ekdz+8xJKq7gvOctjGTjrxT2EtT0as3VtZg0rT728ZGuPsSb 5YoiNwGM9yO3NZ/hO1vbWwuHvZppTLcSNCJZjIUiz8gPJwcf/Xrl7qCCKPx2wkYOEOFaU4OYQT8p OD9aT2foNatep6Hazrc2kNyoIWZA4B7ZGanrz2Ga50fUrb7FcXExn0GS4MMspdWlQLtIUnC9cYUC rnhstez6Xq0PiISrcQlZrUFm844zkgsdpU+gHpVWIudtRXKeLX1GK4gms1a7hhic3FnFcGGUqcYk QggEjB4NULLUVn8QRGO+uRZXOg+eqzTMpJDEbsZ4bHUipuUd1RXmmmy3WpQeD45tUvdl7bzrcGO5 YGXaARk56+/X3qKJ9QS4tdNk1W+NtFrr2kU3nkPJF5ZO1m/iw3GfyqrCud9r2sx6DpM2pTQSzxw4 3LHjIyQM8kdyKmF1K19HALSUxPF5n2jI2qf7vXOe/TFeeaqtzY6B4u0true7sLV4TbyTyF2QttLJ uPJxx19a2r+9u7TxYfs00rbdCkmW33ko0gPB29M8AcVOiHudoaK4TRM6hHp+qR+JN4nt3We2RnLS sRk5y52FT3AHpV7wDbSSeHrTVJr68urieHa5mnLLwx6AnGfen1Yuh11FcNPczanc+KVubye0n03/ AI9RHMU8tAm5XwDzk56544qpZfbdc17SotRvby3NzoyzzwwztH+8D/eAB4PrSWtgeh6HjrRjmuX8 ePNBoVs8F1PbuL23TfFIVJBcAg+o+tY13ZldW8T2K6hfi3tbJLmFftkmUkKsSd2c4yAcZx7UdG+x Vj0KivOLrVZb/SLdjfzNdroZuXTzjCikg4k3DkvkYx/Kn2Ek2s6zpcVzqN0YrjQvOmSK5ZA0m7G7 gjn6Y96Yj0Sqmo38Gl2M19dMVihXJIGSewx7kkCuF0bU7yZfBss19OftHnxTkynEu1fl3c4J9+tV L6X7d4B1xpryecQaoyRs07HC+aoAznkDsD0ptCud/p2oS38k6zafcWhiYBTJjEgIyCpBrRrz7xPc Lbrf29nfXJlsdL80I10yLASSQ+7OXY9ADxxT7XUV1y/uNO1LVZbQppsEsDxzGLJZcvICCMkH6gUh ncm4iE4t96+aV3BM8ketS1wsdrA/jss1zPIzaMrCXzmQyHcRnAI/KqOmancvp3gtpNRnaae6eOfM 5zKAG4bnnkDrTQM9IxRivN4ZLq10TxBrMd/ezXGn3lxFCjXDOipkA/LnnAyRTtTR4ND1HUbLxO0s cummRYoJH4cdJQxclfTHf8KXS4W1sejUVj+HrBbXT0l+0XM73KJI7TzF8HaM4z0H0rkZ9RvLvwxr esfa54NWsL11iiWQgJtYBEKZwQwPTHOaOoI6/U9bWwuBaQ2s17dmJp/IhIDbAcE8kd+B61eS7iMM EsmYDPtCpKNrAnopHrXJpAs/xItZZjKkz6SJXUTMNrb+mM9PapvGcEUuseGmlZ0Bv9pIkK4GwnsR S6B1NrStaj1S+1G1S3lhfT5hE5kx8xIzkYPStQ15hqcZiTxlqEN5cQzWdzFJC0U5QZCrycH5uOOc 1pXt1NrOralp0+tDS5IbaGS2YsynBTJkGGAPzcHrTS0Qu53pGazJ9ait/ENpozQSmS6ieVJRjYAv UHnOefSqWvajeaX4Hub+3mNxdQWoZZQmNx4BfH61zN80dnr+kahp9w9zM2kXMiFpjJvbYDkZJ70b D3R6PRXC6DENUbTtRj8SmVLu2ZJraNn3SsRkt947GU56AU7w1NeXMy+H7u5umutHuXNzMZm3Sp1j JOeQQeh9KLBc620uZLlpxJaS2/lSFFMmP3gH8QwTxVrpivOG1m40+x1ASXs/2U+IPs0s7ykmGE+j E8DPHtV/WruPQ7V/susSta3GoQrO0khkW0jYcgMDkA8Hrxml0DqdzS1zWgxJpk9952vx3dvLIjIj MSICw+6GZjnPXFdJTAWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigCGaGO4ieGaNZI3GGVlBVh6EHrVObQdHubSGzl0u1e3tzuhiMI2xn/AGRjj8K0 qKAMtvDuitZSWTaVaG2lfe8Xkjazf3iMdfepf7F0vyreL+zbXZa/6hTEuIv93jj8Kv0UAZ50TSjH cRf2baeXctunXyVxKfVhjk/WnLpWnJcLcJp9ssqx+WsgiAYJ/dzjOPar1FAGNc6bcafaCLw1badZ u8uZfMiITBzkgLjLZx1qxbaTaRaQmmzQpcQhcOsiAiQ9SSDwcnJrRooAoDR9MSSOVdOtRJGnlowi XKp/dBxwPasTWvC32j7JFp2n6U9nbly9jcQ7Y2ZsfMCoOCOe3euqooAw/D2hRaNHNsgt7czsGaC1 BEaEDHAPf1OBmrk2jaXcSyzT6bbSyTpsld4gxkUdAxI5H1q/RQ9Q2KUek6bHPFcR2Fss0KbIpBEo ZF/ug4yB7Ulpoml6dcy3Nlp9tbTzcyPFEFLfUir9FAFK70yxvpEkurSKZ41IVnQEgHqM+h9KZcaL pl3JBJc6fbTNbD9yzxg+WPQelaFFAHLah4VSbWtHktLKyj0+w8wtCPkJLgcqAMcY9e9Sa94ca/k0 iOztrRbSxuvOeJyVDDaRgAAjvmulooAoNpGmvZNZSWFu9szbnhaIFWPXJBGOtPTTLBLpLtLK3W4R NiSiIB1X+6DjOParlFAGbb6BpFpNNNbaZawyXAxMyRAFx6HjpVmzsrXT7cW9naxW0I6RxIFUfgOK s0UAULjSNOvLgXFzZQSzAbd7oCcZzjP1qQ6bYterfG0gN2q7Vn8sbwvoDjOKt0UAVLywtNQjWO9t YrmNWDKsqBwGHQjPeo20bTGlmlbTrVpJ12TMYlzIvoeOR9av0UAZh8P6M/k7tKsyIEKRAwL8insO OB7U6LQtIgZGi0u0jZIzGpWFQQp6qOOntWjRQBmyaBo0lnHZSaVaG2jfekPkjYreoGMCkbQNHaGS A6XaNDM++SMwqVdvUjHJrTooAzptD0m4mSWbTbWSRIzGrNECQh/hzjp7Uybw7os6W6TaXaSLajEA MQIiHovHArUooAqSafZy3cV3JaQtcQgrHKUBZAeoB6iqqeHNDSQyJpNormTzSRCPv/3unWtWigCl baZYWSyra2cECzEtKI4wocnqT65qCDw5olvbzW8GkWaQ3HMsYhXa/wBRjmtSigCGGCK2hSGCNYok GFVRgAegFVn0jTXvTePYwNcHBMjRgk46HPr71fooApnTLBr4XxsoDdgYE/ljeB6bsZp15p9pqESx XlrFcIrB1WVAwBHQjPf3q1RQBnPoekOs6vpdoy3JBmBgU+af9rjn8abc6Bo940DXOmWszWwAhLxA +WB0A9K06KAImRHQoyhkIwQRwR6YrPtfDeh2UqS2uk2kMsZJR0iAKk9cHFatFAGfZ6JpenXEtxZa fbW003MkkUYUv9cCrSQQpPLMkSrJLjewGC2BgZ9eKmooAzxo2liG4gGm2oiuTmdBCAJPduOTSxaN pkGnnT4tPtls2HzQCMbD9Rir9FAGZHoGkQ2SWMWmWyWqOJFiWMBQ45DY9c1pUtFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAlHrVHVfPGl3L20 7QSrEzJIADggEjggjFczp3ii+vdBvLe8b7FrljCJJAoBEikZWRAQQQf0PFC1A7WiuYs9SvNY16/0 +3upLa20xUSSVFUvLKy5PUEAAY6DnNM0/UdS1DUtQ0J7zybrTZkL3MaLmWF1JXgggNng8Y44oA6m iuR8NT6xqsU1xLq0jCC+mtyhiQBkUkA8DIbofTjpVTQdbm1DTg9z4i8u+N5JBHBtj+ba5ABXGeQO ufeha2B6Hc0VR1aW4g0i7mtnVJo4WdWZdwBAJ6ZFR+H7qa/8Pafd3DBpprdHkYDGWIBPFJAadFJU cskcMTyyMFRFLMT0AHJNMCWiua8Ma9d6neajY6jCILiGQTQp6wOMofqOQa07TWrS+uFitxI4YPtl 2nY20gNg/U0AaNLWZca3a292bY+Y8iFPMCIW8vccKT9az7XxdazvfebDPCttefZEBQ5lc44H45+g 60bgdHRXNzeL7NZNPFvDPML26e2bCHMTIDuBHrkYxV2XxFp0N7FbvKy+dMYFl2nYZP7memeD7ZGK ANaiuTv/ABE8uu6JDp88otrq6eOQ+UPLmUIx4YjsQOmM9s1s6lrdnpbBLjzGkMbS7I1JIRcbmPsM /X0oDqaZpK5CbxWtj4kmeW4uLnTG06O5iSCAuVyzZbgZxgZ5rXk8TaZHCJ4pHuIzALgmFC+2I/xn Hbg+/FAdTaorJh8Q6dPfCzhlLu9t9pRgp2PH6huhpk/iSwt7QXL+cU8nz2Cxkskf94jrjg+/FAGz RUMFxDdW8dxBIJIpFDIw6EHoa5PxB4onW01+3sVmtbjSkRhOyAhs4PcEYwfrR1sB2VFYdp4n064j nDSyxSWqI0qywspIb7pAI5yeBirWn6xaajPcW0LOk9qwE0UilWXIyD9CO4oA0qKwk8V6U91cW6vc D7M7RzSeQ4SNgBwTjqcjHr2pyeJtNL3ETySRz25QNC6EOd/3MDvn2oA26Kxk8SafKh2mTzRObfyC h3+YBkrj6c56e9Rt4r0dbaK5aaXEtx9l2+UxZJf7jAcg/X8KAN2iudXxlpLck3KbbgW8peBh5Tk4 AfI4zx+dOm8ZaPbyTJI84EFz9mmf7O5WNzjGTjocgUAdBRWND4k06cXPzTI9rIsbxSRFX3N93APJ z2qI+L9ISLc0kqN9p+ytH5LFklxkKQB3HT1oA3aKxIfE2nXFs1xG0oK3BtvJeMrJ5v8Ad2nnPf6V naB4hkkfVjfTSyiLUGgt42iCuBgEKABz35NIDraKxIvEunXcMT28ssskrvEsKRnzAy/eyPaofBep XWreHY7y7naaVppF3sgUkBiBwAO1MDoaKyLbxHpl3epaQySs8hIjY28gRyOuHI2n86cniDTpLsWq SyFmfy1cwuIy390PjaT+NAGrRWTP4h0y2vHspZZftKEfulgcsR6gAcr7jinz6ht1m0skk2+arMwa JsOMcbWxjI7jOaANKis++1e1051W588AjO9Ld3VR6swBC/jUWr3d3awwXNpLCYjKokV4yxZWOPlI Ix+OaQGtRWLqWsS6Zq9lbPArWt1uDTBjmNh0JGOnbOaLDWjI/k36JFM908EYi3OrFfU4+U/Wn0uB tUVjTeJdMgiWZ5JwpmaAAW8hbzB1XaBn6etVbvxRatpUl/YXS7LdkaUzwsAYycZGcfmM0AdHRWZB run3CTuJmjWBd0gmjaMhfXDAHHvSWWtWWoM8cBmWSNd+yaB42K+oDAEj3FAGpRWTZ+IdNv5xBbTS yPkqw8hwEYdmJHyn2NNvtSt7XWrK2lvpYWeKWTyRFlJFUZJLY4x6ZoA2KKzrDV7fUX2wpKAYxIrO uFdT0IPeq0/ibTbZL95XlUafIiXH7s/IW6fUc9aOtg6GzRWBdeL9Itbm4hkefNrIkc7CBysW7oWO MY96f/bVnDqmpCbUZdtpHGZIGjwkWehVsZYt+NAG7RWFJ4q06D7Ys3nwtYxLLOjxHKox4YetTt4g 05Lma3aVkeK3W4YshAMbcAg/XtQBrUVmWGs2moXVxZxM6XNttMsUiFWAPQ/Q+1VX8WaXGsjO8wWK 7Fm/7o5WQ9AfbnrQBuUVg6prVtFhDeXFoVvI4C6Q7gzH+DOCMHpmsjWvFlxJo+sy2PnWU2l3Kxb3 jBD8jd1yOh+tJAztaK5298S6fJpmpN9rurNrIATSfZzvi3fdYKRyD60+68XaTYPPDNJcM9qiNOy2 7nYrdGOBjHvTsB0FFY+va5HoWhy6p5L3CLt2iMZzuIAP05rIuPE7ab4ovVvZbhrBLGOYRLAWMRLY JOBnH1oWoHX0VjXniXTbGHzpJXaJUWSSSNCwjRvus3oDS69qMFlpaXL30trG8iKk0EfmZ3EYHIIw emT60AbFFZb63ZLdvbgyN5cnlSOqkqjYzgn6VA/ijTorOS8k85baOMS+b5RIZCcbhjtn8aANuist tf06O7uLeSUpJbQpM+VONrdMHvVSbxjpFtHcPcSTQtauiSxtC25S/wB04HY+tAG/RWCLnUNQv7G+ sZpINPHmLdQXFvsLY6Nzhgcj0q3YazbahNst/NYMhdJCh2uoOCQfr260AadFYUepzXerajaWQBXT oxuH/PSVgSFz6AY/E1meGPEN1rN9HGszy+XE39oRSxhDbTZ4Qfr68d6FqD0OworD8T6pcadpFwbA K16IGkTcMhAo5Yj2/U1XOsz2Vpol7cyboL9YoZsgDY7rw4/4FwR70AdJRVG91GGxMSTbmlnfbFFG Ms5xk4Ht1NYHhrxI02lyyX9xNPcPfzQwRiICRgp4XaAOg60AdbRWEfFmkrb20/nSMLm4NsirCxYS jqhAHB+tMj8ZaRJsOblQ1x9mdnt3AjkzgBuOM5H50AdBRWOniTTnv0s1kkLyStDG/lna7qMsoOOo ANU7TxRpsFjDLNfXN0Lm7e3iZrZg28MfkwBxjGOfSgDpKKz9K1a11m2e4tS+I5GidZEKsjL1BB79 PzqsPEenNdQxeYwS4laKGYodkjjgqG9cgj3xxQBs0lctpOo32uazelLm4tobC8MXk+SuyVAq5BJG QcnPB6VqjWrSW6NunmuQ7RmREJUOo3FSR3xSbsrh1satFc/puv2Z0+2kW8uL1rqSRYS0W2SQqTuG 3AAwAfTp60J4z0aVLZopLiT7UzrEFtpMsyA7h06jBpgjfornv+EgsL3+yZre+uIVu7hkRBD/AKxl BDI+R8uCD6Hism9126urnWz/AGleaXBpUiqXitRIGXaCxIIJz835DNFg6HcUVi3HiTT7GANNJLIs caPLIsZby1bozY6Z9KcfEmmrfLa+Y+Wn+ziTyzs83bu2Z9cfhQBsUVgR+MNIluUgVp8vcm03tA4Q Sj+EnGAasHxDp/2uO38xyJZGiSbYfLZ1GWUN6jB9uMdaANeisi38Q2Fzfx2as6yzRmWEshAmUdSp 79RWsOgoAWiiigAooooAKKKKACiiigCpqMU02n3ENuEaWSNlQOxVckY5IB/lXPa34Tk1jSrJllSz 1WzjCLNGxIK8BkY4BKke3B5rqmZUUsxCgDJJ7UxJ4pSVjlRyv3grA4+tCAwYtGvNL12+1OwSOaLU FQzwPIUKuoxuU4IIIxkHHSptG0aaxv8AUdWumje+1F1LrGTsjVRhFBPJwOpwMk9K0ptSsre1mupL qNYIATK+4YTHXNOS5S4s1ubZldXTchJwDxxk9qNkBj+F9J1DR7O9ivFty893LPH5UhYYYkgHIGMf jVHRNG17SdIaxNrpsspuJJllM7HZucsDjZyRn15xXR2l00ttE1wYYpmTc8aSbgPXB4yPepDdQIqs 80aq3CksAD9KNg3ItSgnuNLuLeHY00sLIu8kLkjHJAP8qyLbwpBdaDptjq4dprKER5trqRFyAATl SuencVrw6nZz389jFOjz26q0qA5K56A/lU5uYFLBpowV65YcUAYP/CBaB/zzvf8AwYT/APxdMm8J w2lu0GkxttuWVLo3F7K2YgckLknk9O3B61t3d00VrK9t5Ms6xl0jeTYrfVucD3xVO81yC3S8jiaK a9tLb7RJbiTHGCQM4OM4Pak3Ydrmdc+HLm18S6fqujrEqRxvBdrPO5MkZxgDg8gjPbrSaT4dvLHX v7QQR2cUgf7VDDMzRzsSCrhCAFPXOP1rY0vU11LS4LxAiyywLKYd+du4ZAJ/ripLe8zaRS3hhhlZ NzqsoZR64PGQPWnrexO69TD1rw9eahrKX1qI7WeJo/KvY5mVwgILI64wwPOM+vaq76Dr0D362clq YbnURdczMjSIR8yEhTt5A5GfwrrXmjjhMzSKsYXcXJ4x65rEHiiGTUdMhgCSWeowySLc+ZjZsweR jvnrmhbjZj2vhbWLT7KyLYg2uqy3ixrKwUo4YY+7wRu+hx2qex8N6laXlzavDp8tjLcPMl2wP2hA xJ24xjIJPOenauqe4hjiEryosZAw5YAHPTmphgjI6UBc4mx8Oa9bJodpKLJ4dHuCwmErBpY9pC/L t4bB55PStLxJpWq6pcols1u9k9rJFJFNIU2yMOH4B3Y9Dj1rfjnilLCOVGKHDbWB2/WhbiB4zKs0 ZRerBgQPxoeu4LTY5LT9A1rT5YJlWzkf+y0snUykBWUk7vu8g59qTT/Cl9oE7jTmhuobixS2lEzF djrnDDAPBzyPaunvNUsbGzmu7i5jWGD77bhx7fX2qb7Vb7I3M0YWXGwlh830ofW/UFoczJ4Oki03 RLWyuvLl04eTLIR/rIWGJF/HAx6U/VtC1Ea+mpadb2F3FJbrby295kbME4ZSAexOR+tdIbiAbszR /KefmHFQQanZ3V9cWUM6PPbAeaqnO3IyP0oDZFWwlv49SlsJ4YPssMKGOaIkEt3BXGB6jnpWHrPh nVrubX1tTaGLVki2NLKylGQAcgKfT1rrXniiKiSRIy5wNzAZPtWTq2uvZ6hHplnDHc3skLzLHJL5 Y2gjjODyc8UdQMfVfCep6ldX8oktYhPaQJCS7NiSJt3zDA+U9Ov4Vt6FaX0EUkl9Z2NpK+AUtPmB x3LYHX07Voi4VYUe4KwsVyys4+X1GfanNcwIgdp41QjIYsACKAOVfwxf3Gn+IbSaS3hOpXPn27ox faRtI3Agd17Z4qKfw/rl5pscpt9LsdRtZ45olt8lJWTOd7YBAIJx1xXX+fD5gi81N7DIXcMkeuKT 7RBvZPOj3oMsNwyPrSSA5280rWr2603VmFqt5ZTMxtVkPlmNl2sN+MluM5x7VVl8K6gSJomtvPm1 db+ZXchVVQRheOTj6V1omiYqBIp3DcuD1HrTDeWwVm+0RbVAJO8cZ6U9g3Vjk7vwxrFxa6xEgs83 +ox3MeZWwFUqSD8vX5fpzSXfhjWJ7TWIl+xBr7UI7qPMrfKqlSQfl6/LXXtcwRoHeZFRuAxYYP0p XuIIvvzIuem5gM0Achq/hXVr/UdRvYWs1eSW3ntlkZmDNGuCrjHQ5PTOKnudD1a8tLJvsmm2k0N/ HcyQxOQoVQRwQvzMc55FaniPXZdBtYJ0tBc+fcJbgGTbgscA9DxUR8QyWurQaVqVn9mnuw32WVX3 RSsOq7sZB79KBGNN4X1kahJqMDWnnx6obyCJpW2yIU2lWO35T6dRUc3hXW5JLi+VLA3P9om8igkk Zo3UrtZGO3r6HmtzQ/FEWs3d9pzQfZtQsXKSQO+QwB4ZTjkfhWjpN9JqGnRXksIg8wE7Q+7HPrge lJDe5z50PWItV0/WrWHT0nhSSKezRikYRsHKsF5YEdwM+1aPhXS77R9ENpeeSJvOkdTExZcMxI6g etV7bxHeagyy6bY289mbhoXmkutjLtbBO3HOecAGugM0SyrC0qCRvuqWGT+FPoHU5rTNH1WDU4JX t4bJEZjObe7d4pQeyxEYUnqT1+tQ2fhi5s5IbV7fz7aGXeJn1GYLjOR+65GfbpWzo2stqf8AaHnQ rb/Ybt7c/PuDbf4ug60zS9fTULzVIZEjhjsJVQSiXcHDLkN04+lHUGIltqieIpr0WlmbeRFj8w3D eYFHP3dmPwzRqMOsSataz2trZyQWxbmW5ZWbcMdAhxj61sxyJIgZGDKehBzmn0AcprmjarqM92sc aSpPCEiLXskaQHbhsqo+bJ5zVq+s9Zm0eztILazaSNYzKXuWUBlxwMIc5x7V0FFJaAYd7Y31/eWb XFvbiEwyR3Kickru/u/LzjHfFVIdH1W002LmG6u4b5rgAuVEingZOOGxjtXUUUwOVg0rWjKrzxWS 5vnuGCTsdqMuMcrywP0qCfQNZawNvCtkXaCOMmSViFZX3f3eQR9K7CikBzV9o+oa6l19uSK0Z7fy YxFKzEncG3EgDA4x696dpWlXkF/9rmsRHJHGyK0mpSz5J9A3AHv1ro6WmBiaBa6nZpNFfWtpEskr S74J2clmOeQVFR6vpV9d6/p1/bi3MVpFMrrKxyxdcDAwRj1rfooA5fw3oF1o15PIu22s5YgDZRzN JGkucsyZA2qfSqOseGtZupNdisxamDVfJdZJJCrIyYyu0A9cdc/hXa0UuodDjL/wzrF3D4gRVs1O q+T5WZWwuwAHPy+1JqnhTVdRudUnSS2ia4jtjB85P7yI5wwx0PrXZk0A01oBwUljqGta5r9jdLbW 95caXEm2OQuinJ74BxmpLnwprWpm6a7NlbefpsdsuyRpNsiMGBPyjKnFdottAtw1wsMYlYYaQINx HuanoAw9Bs9QgWSTULKwtJmULts+Q+P4icD8qztY8HNqep38gmVLS9twzRDOftC8I/4f0rrKKOoH K33h7Up/D1hZpJBLexXUNxcyyuVEjKcsRgHrVXUPDGrz2mu2kJtCmo3a3ELvIwIxtyCNp/u+9dpR QtHcDjtW8NavqEmvtH9kQapbRRRZlb5Suclvl96S98NavcnWtotB/aFjFbxDzW4ZQQSfl6c12VFC YGBrWjXmpeEG0qJokuvJjAJY7Ny474zg464qje6DrF7qGp3Rjs0+26aLVR5zEq/Oc/L93mutooDq cTD4Z1ixvEljt9MvI57WGGdbkk+S8a7cqdvzAjscVseJtIvNW0FbCzaHzRJExMhKLhWBPQH0reop dgOTvPDt7Nr/APalssNnN5oLyxynFxFjGySPGCc8ZqkPBl+dP1O0geKyhvbXZ9lWZpIlnzneoI+V evHvXc0U1oBw154W1vVpL6af7HbNcWcMcYWRpAskbbhn5RlTU97oGtajoEtu1npVndvLESkDMEIR gSS23OTjgY4967KiktAepGdzRngByvQ8jNc3oXh670vV5LxdlpbzRt51rDMzxPKTneqkfL711FFP qHQ5iy0+ay8Qa9CZDF/aoWa3lHYhNrY9xwcVHpnhu6s7+xvTFBDc2lo1vI8Tn/SjjgtwO/PPfNdS QDjIBx0pc9KV7agcxq3hZ9c0+ae5eW31Oa18phb3kiw5xxkAjIyfSq17oUn9jaH4eRmleGaGWdy5 fakfLYJ5wSMCuypuACTgAnvTAwde0vUJtY0zV9NMLzWJdXgmYqro4wcEA4PpxWPYeF9as7u11H/R Dc217cTGEStteOUcjdt4YfSu3xRSWgM44+FdQR7eeI2/mtq/9oXCs7AAYxtXjk4A9Kbc+GdXlstR gX7Juu9VS9TMrYCKUJB+Xr8vb1rszQDTA4v/AIR/Xn1izv7o2UrWt9JN5hmbc0TKQFA24XGe3XFE HhjV4baxjP2Pfb6u984ErY2MzHA+XrzXaUUAYWg6Xd6edV+2eUBeXjzR+U5YhWAGDkDnisqz8K6h Hp1jo9w8BtLC9FzHcKxLuquXVduODzgnNdjijFIDD0DTb7TrrVJLxYNt5eNPGYpCxAKqMHIHPy5/ GqaeHrxPEY1WBY7NjKxuDDM2y6TGF3IRjd05FdRmjNNq4dTzq4srzRLfRrKSSxj1GGe5nRnujGux ixwHK9fnAwQelX9K0+6un0aa1s7WCDTLiYyAXJkEpdT8yMF55bJzjnIrsZ7eC6TZcQpKoOcOoI/W pVVUUKqhQBgADpR6gcZaeGNXhj00P9jza6pLeSYlY5V93A+Xr836VNceHtWmt/E8Si1X+1z+4zK3 y/IE+b5eOmeM111FAHJ2mj6/pWqSz2f2KSG9hiW4EsjfuJEXaSvHzAjscVBd+HtfudTiupGs5/s+ orcwyPKwbygMbNoXAI55712lFAHFN4Z1g2rw/wCh5bWRf/61v9XuB2/d68Va0rRdasEuNIke1bTG lkeO4DHzgrknaVxjOSfmz07V1VFAXOS0HR9X0e1WK5ttKxYwskNymQ82Bhd/y/L2zgnNdBpc93da ZBNewLBcuuZI1OQD7Z7Vd7UtAhB0paKKBhRRRQAUUUUAFFFFAGH4ugNz4T1SFYXnd7Z1SNELsWwd uAOc5xXIXmmXwe4j0awngln0NFYrA0YeQNkqSQBuIyOTnmvSqKQ7nn2qac+q/bJ9LsZY4JNFkimi aAp5kv8AyzUKQMsOfzFdLZJFL4PSP7O0aG0w0ckZQ/d5ypAI59q3Kpahp8epRJHJNPGqtuPkyFd3 BGDjqOelDV00JbpnEaSptYPCF+1rNLANNkgdoomkwzKu0HAOAcHk8VTtrS+Tw1YeRbzx3kNtKjWl 1aM0Vwpckx5HKtwCCDzn2r0q3t4rS3jt4EEcUahUUdAB0FTVTd2JaI5PRLZrfxnqks2nyQNdW8Dx v5RK5C4Yb8YzntnJqHxLoE91rbpa22+DWrU2t3IFyIipysh98Ege4FdnRSeo1oef3On3954B1KTU dPd9QNqbSONYyzsE4BAGTy2SPYinTWzR6xq0p0+4JutGRYZFt2O5wrgjIHDcgY613tFJ638wWlvI 8707ThbXOmFdLnjWTQnjusWrANJ8uFfjluvB5qLR9LWSbw+t7pNw6xaPJFP5tqxCtlcK2R14OBXp NFMEcx4Zt538A2tpcQSpMtsY2imQqQeQAQea5/SNPSUeFILjSbjy7W2nS5SW0baH2qPmGMdQcZ61 6PRR1b7h0seX2KXdnp2krqVlqX9m+RPbukVqXaJi525QqTgrwCBXXyWN1F4GlsdKWaKdbNkt1mbM g44BPr29q6Gihu6sHW557cx/2joElzo+jXttepDDHdI8TRF0VwWjUHAYkbuR24zziovEWnNfprF3 p1lcfYp7GJDAtuwMk4fIKpjOQvBOK9HFFAuh5trGksf+EggstLmEU2n27Kq2zBZJFb5sDGC2Ovep 9RjSbUpLe/sdSbTL6zjS1+zWudpHVCMEoc85OPfpXodFAzz/AFSwa21uHVrfTLqa2gMUF/AImZrn H3ZAAPn2EjJ7/hWtotv5PjTW5WspI/tKwyQzeSVVlEYDfNjGc9R1rqqShAcRq8EzazrkWoWU1zDe WSrYOkRcAhSCmQPlbdzSaZYXUHinRft9rJLNFpXlz3Hkll83IxlsYzjPeu4oo2B6nG+J4bCTxjoX 2+2WeJorhWUxl88LjIAOR1696xrDw8FvdDt73TJZbPzrzCSQMyxwsR5avxgDrgHpXdXOkQ3Wq2uo ySSCa0VhEARjDfeyMd8Vo0k7WB6nn1rZtJqsthfWmorf29889rLHDiEqc7G8wD7oHG0n2xVjw9Cl 1awWt3o90msWcc0c00sTKmWzk7vuvu445ruaM0dLD6nmmlpIyeHIZNNvB9jsrm3uS1q+FYqBtPHI 447GpNP0Vbfwhoz28E2m6ko+eVrMt8y5+WVcZ2nOPbtXoxPNFN6krQ4KyS5F5Zy63pDx2M2mmFIY oWdIZNx3DbgkbhjGfpVfRdAl/tnRYdZ097gx6dIjvLEXVPnzGrNjGQvrzXo1FF9QOU8dxyvptgkF tPOU1CCQrBC0m1VbJJwDgVFrMNx4j1/RltbWeOz0+5N1cXE0TR8gYVVDAEk55OMV1+aM0krDOMl0 afVLV9T00SWmr2N5NJbPLEY/NUtkowIBKMP8a3PDSzjwxZC9t2gmMWZYWGdpJOR71sUtPoHU8yj0 518HwIulXC3Ca0JCv2RgwXzSd2MZxjvV17Y3PiC8s9UtNSaZr4XFnJDF+7ZBgr+8A+XaMggkV39F JaA9TzqeK/jhvpvsN09quvme5iEDbpYPUD+IZweM5xSLbefd6y9vHe6eJdRhntpxYsVyE6shHK54 PpxXo1FGyBnPeGr2dbG0srzT2tbl1kY+VE3lYDdcn7u7qAa6KkpaYBRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFVr y7hsLV7m4YrFGNzsELYHc4AJqE6vYf2WuqLcB7NkDiWNSwKnvwM0AX6Kz7jWLG3kjjeVzLIu5Yo4 2d9vqVAJA9yKZ/bmnizS7WdnjeTy18tGZi/OV2gZBGORigDTorFtfE+k3soSCeVy0jRgmCQDeuSV yRjIweOvFLD4o0q4h8+GWV4d+zzBbybQwOCCcYHPFAGzRVa6u4LK2e5uJVjiQZZj2qtpWt6brUMk un3QnET7ZBtKsjehUgEfjQBpUUVU1HUbXS7KS9vJDFbxDLybS20epx2oAt0VmDXdOa+trLzz591H 5kKGNhvXuc4xTLjxFptrceRLM6yeetv/AKpseYwyFzjHTnrQBrUUUUAFFFFABRVC/wBVs9MZEuXf dIGZQkTOcL1J2g4AyOTVJPFujPbG5W5kEAiMwkMDhSg6sCRyOe1AG5RWTbeI9KvC4huSXWITeWY2 V2TswUjJHuBVrTtTs9WskvbGdZ7eQkK6+oOKALlFZ+n6vYaqZ/sFwJxbyGORlB2hh1AOMHHtUyXU TXr2a7/NRA7ZRtuCTjDdD06ZoAtUUlLQAUUUUAFFUV1S1bVZNLWRvtaRCZkKkDaTjIOMGrm4ZC5G SOBQA6iiigAooooAKKKqpeQy3U9su/zIMb8xsByOMHGD+FAFqiqMeqWkuqTaYkrfa4IlkkQoRhSc A5xg5xV6gAorJn8Rabb38li8spuYkDyRrA7bVPQ8Dp71csr+01K3W4sriO4ibjfG2Rn0oAtUUlUd T1ey0iFJr6YwxyOI1bYW+Y9BwD1oAv0VkTeI9MgvXsmklNykYkeJYHYqp78DpV2x1C01K2W4sriO 4iPG6NsjPoaALVFFFABRRVH+1LU6s2liRvtYi87YVIGzOMg4x1oAvUVXurmKytZLqdisUKlnIUnA HU4HNFndQ31pFd27b4ZkDo2OqnpQBYoppIAycAd81nWWt2OoXZtreV3kCeYCY2VWXOMqxGDz6UAa dFJS0AFFN3AEDIBPQVXtLyK9R3h37Vcod6FeR9RQBaooooAKKozanawalb6dJIy3NyrNCuwkMF68 4wPzp9rfQXiM8RYBJDGfMQodw9MigC3RSUtABRVDUtVs9ItGur2UxxKQpYKWIJOBnAOKvDoKAFoo rMOvaf8Abbmz81/PtU8yZBE+UX16UAadFYtv4r0W4ihlW82Q3BAhlljZEkJ6BWYAE1s0ALRRWa2t 6euoy6f5rG6ij814xExIT16UAaVFYkPizRJoY5xfbYJTtSaSJkRjnGAxAHXitoHIBFAC0UUUAFFR u6oDuOCATgcnAqkNWsxYR3ru6xTEKm6MhmJOAAuM5J7UAaNFZula1Z6wkj2TSlY22t5kLR4PPA3A Z6c1o0ALRTSwXAJAz0p1ABRVe4uY7WMyTNtXcFHuT2HrmpwcqD7emKAFooooAKKaWC4BIGelOoAK KpXGqWltqFrYTSMtxd7vJUISG2jJ5xgcUlzqlrZ3trZzyMk14xWABCQxAyecYHHrQBeopB0paACi qOo6raaXEs13KUjaVYgQhb5mOADjpyRV2gBaKKKACioLiZLaCSd922MEttUk4+g5NSQypPBHNHnZ IoZcqQcEeh6UAPoqqbuJb5bT5/NdDIPkO3AIB+bGAfarI6UALRVa9u4dPtJby5YrDCpd2Ck4UdeB UltcRXdrFcwtuimQOjYxkEZFAEtFFFABRRRQAUUUUAFFFFAFPVP+QXd5/wCeD/yNcBdQzeD9JZYV eTQtTiA2Jz9jnYDp/sMfyP1r0SeCK4haGeJZY3GGR1BDD0IPWmi0thafZBbx/Z9u3ytg249MdKFo weqOX8O74vG/iNLvi4k8hoSx+9DswNvsGz+NL4bjZ/GniW4iGbIyxBDj5fOCYcj35ANdJc6dZ3pQ 3NrHKyZ2syjK59D1FPit7e0t/JiijhhUY2KAqj+lLb7rAznPAgVtO1LOGxqlwR7HeazfCAvB4eaV b21js0vp2lSSL5iglbd82cfp7V2NtplhYxyR2lnBAkpJkWOMKHJ6k461XXw7oiLtXR7JRu3ACBRz nOenXPNC0sD1v63Ld1LbQ2puLpkWCP5yz9Bjoa523le0ur7VrGw+33eoOhNrBNGrRxKMKzbiBk/1 x2ror2wtNQtjbXtrFcwHBMUqBlOOnB4qKw0fTNL3/wBn6fbWZfG8wRBN2OmcDmmBlf8ACQ6//wBC be/+BcH/AMXT47vUNbSbTtS8OXNlbXELI8ks8TjkYxhWJ710FFJq6sB5Ot5fw6ZZajKH8zwjcfZ7 o45lQtsb64Taa6DXY5DoOlzMxhnvNWhmY4G5SxJA57gYFdebO2ZZo2gQpP8A60FRhzjBz68U260+ 0vFjS5top1iYMgkQNtI6EZ6H3p3A4v8At+/sZLiwnvjJEur/AGT7TM4Uqhj3AFgMA7uM49qmludX guNJsn13d52oSRO8O1j5exmCliOSOOQPrXUyaNpUsVxC+m2rR3Tbp1MIxIfVuOT70q6NpaR28a6b bBLU5gHlD90f9njj8KQGd4QvLq60y5S6uGuXtb2aBZXxudVYgZxgZxWNZ63dSeIdMMeotcWt7cXM bs21Vbb0Cpzjb0znJ9K6+0sbWxDra20VuJGLuIkC7mPUnHf3quuhaNDN9pXTbSOQSGXzBEoIc9Wz 6+9PqBNqSr/Zl25AyIHGfbBrkbUI3wYVzjK6QwB9PlrtZoYriFoZo1ljcYZXAKsPQ+tV10nTVsDp 62FsLMjBtxENmP8AdxilbRoFo0zmtJ0Ka4bTddurtD9k03yoIo4yv3lGSxJPp0rJ0WSfQLj+x7UN 5OuQLPZsg4ikPEv04+YV362dtFafZEt4ltwu3yggC49MdMUkNja28cSQ20UaRArGqoAEB6gDsKd9 X2Fsjmvh/BFaW2s28OBHDqsyKAfTFGo3+qJ4g1iztL5AUsIZLeOUhVR2dgRnHfAGTnBIrpLXTrKw Mn2O0gtvNbdJ5UYXcfU46mo5dI024mlmmsLeSSdQkjtGCXUHOCe9LsPuZ3hbUXvobtJ1uorm3mCT W9yQzQttBwGHDL3BrBudc1GC1v8A/iYMHt9dS3jztz5RYfIfXg9etdtbWlvaIyW8KRKxyQq4yfeq k2g6RcXElxNplrLPKQZJGiBZsdMnvijzDo0c5Nrmo6fq9yt2JXJFw1lJCweCcKpZY2A5Vxj8fWqc 3iDU7PRW16HVILiGWzDGESCQq5YDzAMDaF3cj2rtYdKsbeYzQ2UMchYtuVADk9T+NR22haTZmc2u m2sP2n/XbIgvmfUY5600DOf0yPyvH7EXj3Ik0mNtzsD/ABnpjt3puu3E1n43juo5ZWMOkzypAG+V 2B6Y98fWujs9D0nT5RNZ6bbW8gXaHjiCkD0yO1TTWNpcXMN1NbRSTwZ8uVkBZM9cHqKT6WDvc5TT tVvzc+G7mO8e7j1dG+1RkAhcLu3LgfLg8Vf8ST3q63olnbahNZxXskscvlhcsAuQQWBwa2bbStPs pWmtbKGF2zkxoFPJyenvWfrehyatqulXLeS0FjI7ukmctuGOOOMU9GJHMW9/rklxYaZLrE6qdTub M3KKgaaNVyrdCMjp6e1TXWsan/ZWuXkV9Kt3o10IYYWC/vFXH3hjkvnqPwrsTpGnHyM6fbH7McwE xg+WfVeOKJdK0+e7+2SWcDz8fvGQEnHT8u1C3Gc1JqGpW+vTaZNczK2qRxy2B4/cn/loo47cnn1F V9V8QahpFx4i/wBKeVLP7KsJYA+SJMBmPHbOea7RoIpJ0maNWkjB2ORyueuD71A2m6aJJ5Hs7UPd LtnZo1zKPRvX8aQHD6lfSaB4g1i8gu3uCun22JJGB2K0pBbOOnOehxXT6EbwXV2s2ow3lswSSCNJ PMaLI5y+BkHqKuW+gaNa7vs2mWke+Py2KQqNyH+Hp09ql07TdO0qE2+nWkFrGTuMcKhQT64FNAzB tGA+J+pZYD/iWQ9/9tq55dTfTdY1+/090i0y51C3tzNnbGsmMSODgjqACcdTXeTaLpFxdNcT6baS XEgw0jwqWYe5xk1M2n2b2RsmtITaldphKDZj029KSBnI3s2tadp09/8A2stzDZXiSvHEwY/Zz95G bHOOoI7VF4qma68MQ37TForrVLeSBW6Km8Y/PrXYW2l2FlZGytbOGG2IIMKIApz1496LnTLG9hjh u7KCeKIgxpLGGC46YBHFDBbGFaso+KGo/MP+QZF3/wBs1W8Kr5vi/wAS3NlxpryxqCv3GnA/eEfo DjvXRyaDpE05uJdMtJJWXa0jQKWI9CcVbhghtolhgiSKNOFVBgD8Ka0B6nDa7qGqw3fiUw6vPENN ghmgRQmFJGSDxyKL3XdU0aXUnW8ku8aTHeIsgU+W5baSMAcAc4PpXXzaPpczXDzafbObkATs8Snz QOgb1A96cml6asonjsbYSGPy96xDOz+7nHT2o6AcdrGvaloEjyWtw99by6WbkmQA+U4IG8EDoc5x 7VBqkk1prNzeW2pSzTf8I+00UpZTghs5HHTvXb2+lafZxvHbWUESOu11SMAMPQ+3tUVt4f0a0O62 0u0hJQx5SED5T1Xp09qAOam1a4nuZrd7zzIpfDpuHj4x5hB+b16VWsdRu3tNK0WG8Sy8zSEmikaU Jufpxwd23qRxXXReHtFgG2HSrRBsMeFhX7p6r06H0p0+gaPdW8NvcaZayw25zDG0IKx/QY4oAh/f z+F2+0XSyTm0O+eHgM205YfWuV8O3NxZWfhCGO9k+z3kUqyqxBBwuRg9q7t4YZIDA8StEV2lCvyk emKqtoekvaxWjaZam3gbdFF5K7Ub1AxxRsw6HG2es6pe2uiD+15l+06lPbysoQl0XdjnHB4qTTNe vGkstKvNRcRy311bG6YqHfy+UXOMZOevtXWpoWkp5QTTbVRE5kjxCvyMerDjg+9JJoOjy2r2sml2 jQSP5jRGFdrP/eIx196GBzMS3H/CZ6LFNrUt3ttJ8yqAquQ2OnTOOMjriodM16/uX06xur1yl3qF 1DJccBsR/dQEcDP9K7E6Xp5Nuxsbcm1H7g+WMxf7vp+FM/sXSvsxtv7OthAX8wxiIAb/AO9jHX3o A49dW1l720sH1OVUTWJLMzKq5njCZGcjqOmRTrLWLyW1jsJtUmknW9uYVxtV5kjGQWfjaBnJI69M V2J0nTXEIaxtyLdi0OYx+7Y9SPQ+9QnQ9FcYOm2RAlMo/dLxJ3bp96lq0PqcppN/Pql74PvLqYSX EsN0HYEckKRn9KqJeXmotor3eoTMy67NEWBCgqudoOOOO1dzDomlQPC8Om2sbQbjEyxAFM9cHHGa P7F0jyfI/s20EIl83Z5K7d/97GOvvVNoSRzrXupW2uXfh6W8mea8dZrGfAykP8Y6Yyv65rrYpopQ fKkV9h2ttOcGs2zsLwajLf6lcW8rrmO2EKFRHGTnnJOW7ZqfTdKtdNe5e3jRDdS+bJsUKC3+NJbB 1OB1oMLTxjvu5W/0uBVV2yF+704rRvtc1HRLzWLZr9riKKW1xLOVBhWXIY5Axjj8K6ybRdJu5JpZ 9OtJpJsCVniVi+OmSRzin/2TpjtM32C2Y3C7Jj5QzIvofUULRWB6u5R8Pi8SW9S51GK8i8xWgVH3 mJSOhbAznqKyEI/4TnxNyP8AkGw9/Zq6ixsLLTbcW9haxW0IOQkShVz+FMOkaa08twdPtTNOu2WT yl3SD0J70mCOJiksx8FI0uirB7EpGufmaQk7QvvnpT7W/wBYnibSJNRj0+/sLG3ZWmk25JX5mK4+ ccY612Fvomj2bI1vptnA0f3NkKrt+nFPu9I0y/niurywtriaE5jkkjDFPoafULaWOcutR1Gx157G S7kddVtkNgQBiOUcOBx6HdzSwjy/iNqEZkLldGjBZjyfnPJrqnhhkljlkjQvFkoxHKkjHB+lQNpW nNdvdtYWzXEq7HlMQ3MvoWxyKVtLAcbpE1hH8ICdQZDA1vMpBOcku2AB65xWvpU2paR8N7e4uo2e +tdPDMjcncBwD+GK14dA0a2KNb6TZxGM5QpAo2n1HHFXsq6dQynr3BpvuJKyscVd6xPp2gjWrfWv tKz2sbvEwDCMsQGkBA+UDJGMYpmsXerafpF9PBriMpntzAI3WVo1dsEFiOQeo711droukWkc0dpp 9rFHcZ85UiAEnrn1pkfh/RYbI2UelWi2pcOYfIXaW7HGOtLqM5z7JcWfjgxPrF5MV0p3V5WX73mD tjH6VQM1xqmh+D7q7vZTNLfrvcEDcctz068V3MumWFxPHNNZQSSRIUjdowSqnqAewqP+xtI8iFBp 1mYbdt0K+Uu2M+q+lNAzlLrxBfWF/qsMt8/kR6jbW4lZV/0eNx8xHHr3PrV28uJbOaGwXXZLkz3L GOJVXdt2E7DJ2APzZ69q3zpOlyrcZsbZ1uwPPxEp87/e9ajGg6N9nitBplp5Nu2+OLylKxt6getK zC5xtlf3epv4TvLq9kaVjdLJscBXKBsZ9egrS8P6pqGqy2OpDUoVSR5I7m1Mm4k5IChcDaVx6/Wu jXRNKWOKMabaiOGQyxqIhhHPVgMcH3p1vo+m2t7JfW9hbQ3Uv+smSMBm+pp3QrGPq8sj+OdAtGz5 Jinmx2LhQBn6Ak1XsNQn1e7uJm1b7FNZ6kYGtsAhoxjClfVs53Vu6hpy301vOp8u5tJN8UmM4yMM D7EcU46Rpp1D+0WsLc3uMfaDGN/54pIZxiarqdpo+oavPq08nkak9ptfYsccZdRuOF6gHr0q9Jd3 tpKttLrayJdXUa20ULCSQqVJKGQ4AzjOeuK6eLTNNjt5oYbK2WC4JMyLGAshPXI71Anh3RUs1s00 q0FuknmrF5Q2h/XGOtHRh5nGaffXep3nhuW6v5S4u7yJikgwwQOF5xyeKt2ut6leRjVYr6EG3nmS ezMm5nClgECAcHgHOa6saJpKoqLptqqpJ5yAQrhX/vDjr706PR9Nhv31COwtku3GGnEYDn6mmLqc dZ3Lahq/hDU5L9p5LtJpHXI2hjEcgDtjp+HNa3i2Fp9Z8OxLcPblrtx5iEbl/dN0zx+la8Wg6LFO tzBpdmsquXWRIlyGPU5x1qzd2Fpfxql3bxXCq25RKgbB9RQtLBu2cUNR1qy06e+m1Ca6t9G1IpO+ 0ZubbAyTgYJXJ6dcV1eiSTXNrJeSTM6XUhkhU/wx9Fx9QM/jUeo6bcTxw2FjLbWtiwZbiLyjuZPR MHAPXt3rWRFjjWNAFVQAAOwo6D6nmkyyf8Ixqm69kkf+31QeawO3Eyc1fm12+0m61Gylvnmhi1GC FbidgpiSRcnLAcc8Zxxmuul0TSZTK0umWrmZxJJmFTvYdGPHJFOfRtLkW4V9OtmF0ALjMS/vcdN3 HP40kDKfh4XqR3MV3fx3gWb90UbeY0IBClsDJH54Nc7ca7qcmk32sQXLrdWep/Z1tMfIyBwu0jHJ IOc+9dnZWNpp1strZW0dtAn3Y4kCqPwqM6Vp5vDeGzh+0E5MnljJI6HPr70+odDk0uNVmt/Ed6db uVbTZpkgjUR7QPLUjPy9iTRPquqyxW0S3UoeXR0nt2hwWa4OOXGOn14611Y0nTEjuE+w2yx3RJuB 5agSk9d3rWDqfhEXuoLKlppU9osSxRw3NtnyAM/cIPQ56e1AeZGt1q0Gt2lhdalIXk0iSWUYT5Zg V+YYGOMn2rM0rW9ShTQ7u71iV47/AE+aS4MqqVQooIcAAGuusfD+n2kEKtawzSxRGIStGN2wnJUE /wAPtUqaLpEfkqumWieSpWICFRsB6hfTPtS6gcYmq3kyajaT3jT282hm5UyEFmY5ywA+6CP4ecV2 Xhz/AJFnS/8Ar0i7/wCwKbH4c0SJdsekWaAoY8LCo+Q8lenSr8EENrCkMESRRoMKiLtVR7CmBLRS UtABRRRQAUUUUAFFFFAFDWNSi0jS57+VSywjO0dSSQAPzIrFbxPeW0rxXWnMDJLHFaSYZEldzjad wBG3GScHI6Vualp9vqunT2F2haGdSjgHBx6g9j3rGfwdFcaZ9jvNW1G6dGRoLmSRfMgKHKlcADPq SCTR1DoV7rxZfWEuoRT2UDtYz20bFHIEglIGRkcEZ6c/Wm654gZbTXoLjTYLqPTjECjyECRXwQTw eRkcd8dqhtfDkl7qGu2V9NeGO5+ztHeMoDOyAHcOMcEDjGKvy+DLe4i1FJ9TvpDqQQTvlAcpjBHy 4HT0oQEGoeJtXt7zUrWy0q3mGm28dwxe4KmRCCSANvDcH296il8Z30sd7PY6dA8NtYRXwMsxVmRg SRgA4OB9KcmjXF34q1dZJruG1uLSGEyBABMACGwccHkcj1OK0JPCVm7Xvl3NzEl5ZrZsiFdscagg bcgnOCeuaWo9LlJ/GU1pNJ9vso44WsReQGOQszAsF2txwckdM9aL3xVqdhY6hdSaSHW1VHjkJaNZ AxwVwRncM/Q+1W7jwfY3Lp9ouLqaNbH7EY2ZQCmQc8AHdkA5B7U0+EFn0ebTLvWNRuUlVVEsrJvR VIIA+XHYZJBJ9aelyVexnax4p1i30/WoVt7eC7sooZY3VyylJDjuB8wwfauwtzI1tG023zCo3bc4 z7ViXnhG0vnv2nu7o/b4EgkwVG0IcqRx1ye+R7VtW0LwW8cTTPMUXBd8bm9zgAfkKBjbuaSC1lli jDuiFlRm2hiBnGe35Vy1j4r1a8bSgumWq/2tatNBmdvkZQCQ3HTDcY9K6q4h+0QPDvZN6lSy4yMj tnise18KW1mdKMV9d50qNo4AxQ5DDB3fLzwB0xSW4FJPFl1Polrfx2cUbyrMJN8mQrxnG1R1bcQe g4HJqNfF+o3ZthY6dDm40z7eplmIx6qcCrMPgi0t1tli1G+U24mUHKZZZTllPy+vcYPvT7Pwbb2R hMeoXjeRZGzXcU+4TnP3etGo9CO18WzXkkIjtECz6V9vQljkH+4eP1/Ss66v7nXr7wwXt4Daajby yy28jEqTtHXjnAY4rUXwZbxRWaQahexm1tDZllKZkiPZuOo9Rg1La+FLe1bSWjvrs/2VG0cAYp8y sMHd8uegHTFVpcnUoWHiQafdW+mS2iW9ssEzKschkMIix8pbkHKnOAcipLrX9abQrjUrexhWBrB7 mGYyZ8pgMhWXqTjnI9KltPBNnaSWjC/vJY7QSrFE5Tbsk+8p+XJHvnPvT7LwhBZ2MunnUL24s3he GKCV1xCjDBCkAE8dM5xU6tPuNWTXYr2PiLUA8Fpc28Mkr6V9tEgc4JH8J4/Wmx+K9UvX0iKx022a TUrNrkGW4ICEbcjhT68GrTeEIv8ARWXU71Xt7VrUuCmZIj/C3y9vUYNSWPhS30+fTZYr27c6bbtb xKxTDIcfe+XPYdMdKrQWpWtvE17ezwPZ6a09rNK8RYBh5eM4YsRgrkY45qrFqupa54SuNXktYLQR 27T2rRzF3EiZ68AYOMdeQTWlY+FYtOvJZLbUL1LaSQyiz3gxRu3UjIzjPOM4zTToDWHhZ9BsJpZh IjRLJMVyit94nAAOATjj0qdbPuPr5Gpo9/8A2potnf7dv2iFZCPQkVeqtZWkdhYwWkIxHAgRPoBi pmXchXJGeMjgj6U2JXsc7pviW61HU0tfsltGG3FkF3meIDoXjKjAPsTVmPW7l4rORrKNfPumtpf3 xPlkZwV+XnO32os/D7wXVtLc6pc3qWhJgWYJkEjGWYAE8cfzzTG8Nh7xJP7Uu0hhuvtMcCBAquc5 ycZI5PGe9A+5UsdT1GyivWFk09la3cqtLLcky7Q3JUEHIA9SOhq3qd1eJf2Mv2aNrP7QoSVLpldi wPJTbgj8aE8M+W0yf2retBczGaeJimHJOSAduQD3Ap+pC7ury2s4dPmSGKdJGuWZPLCgdAM7s9B0 oXQCtqviyKw1K4s4zZFrVQ0oubwQscjICDBzx64FW31q4u3gj0m1S4eSBZ2M0xiVUJwOQpJOQe34 1Jd6LJLdSXVpqE1nJMAJdiIwfHAPzA4IHHp7UXGjvJLHPb6hc2twkYieUBWMi5zgggjPuPWktgKd 5qmtmHSpINPjgluJts0E8+0jg8ZCn0zmtyBp2hUzokcpHzKjlgD7EgZ/KqM+kGWzt4BfTie3fzEu GIZ93PJyMHqe1XbSCW3gEct1JcuOskgUE/kAKYE1cDqMbX2t+Jf7Ss7a+t7C3jkiikkZduELYBxx nnNd9WK/hqB7rVJze3W7VIhFKoKYQBdo2/L6euanW49DOj8SyJY21vpunqZhYJciABioB+6gKg4P HXpVT+1YrDxRqGs3du9uF0WKaWE43A72+U+/atN/CEH+hS2mp39pPZ24tvPhZd0sY/hcEYOPXHFT T+FLG5ubiSeSeWO5sxZyQsQVKAk5BxnOTnOarzJW1mZVu91N8QbC4uYYomm0t2HlsScFgcHPcetd kKwLDwuthqNrfNql7dSWkBt4xMUxsJ6HCjPTrW+KFsHUyNR1aWHUoNLs40e7mieYGQkKFXjnHqTV JfEGoTyyWUOnxx6hbWi3FzDLLlVJJwgI7nHWreseH4tWurW8S8uLG8tSwjuLcjdtPVSCCCD6Ypkn hiAXq3lvd3NvcGAwSyKQxmX/AGsjrnvS1t5laXMlPGl7f+U2m6bCyTacb1TPMQV2khlOAecgin2P iLUdR1+yEEUYs59L+1iEn5t27BGelaKeEbKKdZIJ7mFUsjZLGpXaEJyTyM5yeuaig8H2UP2YLeXn +j2bWRyy/vYm/vYHUZ6jFMS8yoviq4uPttncWMEjLpzXexZcqRyGjLYIPTqM0kPiO8RdLstN0u2C 3Omm5jDzFVj2gfLwDxVmDwVBBj/iaXzkWTWILFOIz9F6j1qzb+FLa3ms5UvLvdZ2bWkYJTlD3Py9 aAXmZi+Ni9tpjmKK2bULfzI2uGIjd92DGHxgHvz1rsVOVBPBxXMr4OtRpKaSb66lsli8lopQjBhu 3Z+7w3uK6SONYokjUYVFCjJ7Cm7CVytqE8lrYT3EMInkjQssZcKG+pPArL0HXn1S+vrKaJN9oIz5 sZO2QOueM+nTPOetaOrabFrGl3GnTtIkVwu1mjOGHfI/Kqml6BHpuoXF8t9dXEtzGiSeaVwdgwDw o5x+FJeY2bGecVzmr6/qFnrL6bZ2MEpFi10ryzFc7TgggA10e3nNZF14fhu9WbUXu51lNq1rsTbt CtyTyCc/jS1BeZnWviq41ZUTTbWM3H2Fbx0lkIAB6KMDqcHmqsfjS91DyDpunQkT6e12pnmK7Srb WUgA9wf/AK1X7bwfbWP2Z7O+uoZYLX7K0uVLSx5yA3GMjsali8I2MM8csE9zCIrNrNY1K7QjHJPI JJzz1psB1j4s0u6trAz3UFtdX0SvHbPJ82T2H41mWXjDULiSzefToYre5v3siVmLMrAkBsYHHFdD pWlRaRpdvp8TvKlumxHlwWx74FZcPg61ghtY1vrwra3pvUyUyXJJwfl6c0aArla18Wzzw6dK1mg+ 16i9k+HPy4JAYcc9Olc+8MaaPKAgGzxQNuP4fmHSumXwXbJNE6aheJHDeG8hhBTajnOR93JByeua c3g+1Ns9ub682vf/AG4kFMiTOcfd6cUuzH0aOkFQ3NrDdwPBPGskbjDKRwamHSq15byXVrJClxNb M4x5sRG5fpkEfpQ9hI4PSII4Nbk8GXciy6ckrXNrK33p8HJiJ6EqevtxXc38Nw2lzQ2JjinaMrCX 4VT26Vl3/hOzv9NsbM3V1C1hKJYbiEoJd47k4xz345q5NplxL9oI1a8iaaNEUrs/dlf4lGMZPft7 U91Zh1ucJJPPoHh7V7IWIsNVV4UmnhmeRZUkYDzELHI75HapvFF9ceH9Q1DTtLZoYJ7KA4Q48pjK ELD3Kk812T6Daz2dzbXkkl210oWWWXAZsfdxgADHsKi/4RmymjuhePLdyXcSxSSSEbgq/dAwOMHn PrR6h6FHTz/Zvjq40m1GyzfTknMY6K4bbn8R19a6rtWZYaPFY3c1400lxdTIsZllxnYvQcAD3rTH SgDkPEFrBc+PPD8c0KSRyR3G9HAIbC5GR3waqXCf2b4xn0WEmXTdQ02S4e1diywuvAKg/dB9OnFd FqOgJqGsWmqfbrm3ms1ZYhFs2/MMHIZTTYPDttBNeXBmnmvb1PLlu5CC4THCrxgAegFIL6nIWt5c aLoo8P61K1za3trv068k53cAmJj/AHh29RXoVmipZQKoCqI1wB24rNvPDljqGgJo18ZLmBFUK743 gr90ggYzx6VsRrsjVB0VQKYWI5SwicqAzBTgE4B+prlND18XNlp1hY2EFvPeJNJ5O4mOJEcqTwOc n+ddZIu9CgJUsMbh2rnYPBdrbJYG1v7yGewMnlXAKFirtlkYFcEZPpmlvoFzG8LazJY6Ba6dDbhr yRrmXbhmRVWUjHAz1IH+cVpnxPq7z2trHo8cNxcWT3JS4mIMbKcFTgfkacvga3hhtha6pfW9zayS PFcoy78OcspBGCM9iKv/APCNQG+gvPtt35sNs9uMsp3BuSxyM5zz6e1Nu7DRGRZeJNR1TWdI+zxw pa3mnvcPEzHO4EAjOOnPpVCa/mvdB8O/ZLK3tbe71Ixy2wYlOHbg8cgkEmt+z8JWuntp7QX14HsI XgRiUzIjHOG+X19MUkfg61istPtFv70Jp9ybmMkpksSTz8vTJNCsLW5VtdU/saTUNHjsIbd7QJJa QpIxE4kJ6Z6fNxjtmor/AMRTaTPr1wmlW5ubJLcu4mI84NnGeOMc1fay/tbxPDez6bNbjS96pNKR +/JxjAB5A689wKW/8IWuovqbS312o1MRiYIV+UJ0C/Lx39aXmMrz+LLnT/7XS+sF82wSKVBBIWDq +QM5Axgjmr2laxdXus3+nz28ISzCEXEchIfeMgYxx0Pf0qhr2gzJFqN9ave3VxexRQSxxMgZY1PL JkD5uScE81L4Xs761lkBmu2sinEd3BFGwfPbywO3r7UxHS9q5q+vr5vF7aViI2Laa8rKc5J3AZ/X pXSnpWVd6JHc6umqLczwzJA1uVj24dCQcHIPcdsUmrpopOxy3hTXbjStH0azuLeMWdxbzNHKJCXB QsxyCPT3re0rX73Ub2AHT2+x3UHnJOqsBGeCFbIGcg9R6U238G2VvHpsX2u6kj05ZFjVyhDhwQwb 5eeCemKn0Tw2uiYSPULy4t4uLe3mcFYR6LgZPHHJNMmxuDpWLqeqONUTR7WOOS4mt3ncyEhVQEDn HUkkCtodKx9T0CLUdRttSju7izvLdWRZYCvzIeqsGBBHek1dWKWjOa8L6vJp/hjTNPhgDXUy3EgX DMqqsrAjgEnkgVrW/ie8F5p8eo6cLFL2CRx5j/MkiclDx3AJBpF8EW0VlZxW2pX9vcWUjtBdIy7w HOWUjGCpJ6EVoXnhyz1DT7azumlmFtMsyyM3zswOTkj15z9ap7kJWRl3Gu/ZtVsbjUNNiVjp81wJ 1cl41XaSoBA6girLeILyzsZNTvrFFsTaC5SSKTJDHGIyO/BByOKuahoFrqOqRX9xLMfKgeDyQR5b q+N2RjPYd6qWnhG1h0yTTbi9vL20aIwxxzuP3SegIAP0JyeKnoV1LOlapf3l/PbXdgYoljV47hQw Vieq/MAcj9a2R0rJ0bRW0mMpJqV5fMFCI9yykovoMAfn7VrDpTA5zxL4iudCEsqWsUkUMBmJZ/mk weVVRyOOcniqWo+LdRt5dUa306B4dOgiuHZ5yC6MCeABweDWjq/hO21e8ubiS9uoRdW32aZImXay 5JHUEg89sVG/g22liv431C9b7fbpbzElPuoCBj5evJoXmBleK9Xk1Xw7r1tZwxvFZW481pGIYsy7 vlx0wCDnueK7Gw/5B9t/1yX+Qrn7rwVbTm88vUL23S/gWG6WMpiXaNoY5U4bHpXQ2sItrWKAOziN AoZsZOBihbAyHVJprbS7qe32+bHEzJu6ZA71xUdzqN3e+ENQaOGS/ntJWJLFVOYweTgn3rvLiBLm 3lgfOyVSjY44PFYdp4UhtG0xl1C7c6XG0cG7YflYbcH5ew6Ug0Klp4xmv7O0ENoBezxSSPHh3VfL bYQNozyelb+lXk19psFzc2r2k0iZeCQ5KHuKxB4JtoYLQWmp39tcWbyNHcoy7yrtuZSNuCueeldD a2wtbZIVdn2DG9zlmPcn3qtBak46ClpB0paQwooooAKKKKACiiigCGeZbe3kmkJCRqWYgZ4HJ4rK sdfN9yul3kYaEzRMxjKyAdgVYgE5HBxWldxTTWc0UE/kTOhWOXaG2MRwcHrg84rH0nw/PZ6i17O1 kjNEY2WytzEJSSDufk5PHHpk80g6FqPWUuRZKkNxGuoQl4pflwhxnBGc5xz0I96o6N4heWytftdv dFHbyTesiqjvnA4ByMnjOAM0ttoeqwT2O7UrcwWCskUYtjlwRgFju6jjoMdfwLLQdShtoLC51KGe zhkEh2wbXchtwXOSAoOO2cDFPqHQsrqNw2vx281reW8To6xh/LMchBB3Ahiw46ZA60XHiKGCaUC0 uZbe3fZPdJs2Rkdc5YMQO5AOPwprXIv/ABDa+RDcBbUS+bJJA6KCcAAEgA556Z6VTufCSPfXE9vD pbJcymRmurLzZEY8tg5GQTk89M0LoHc0r3WxbzSw29hdXxhUNN9nC4jBGQPmIycc4GT0qvca9dJf 2EdtpN1cw3ds03yFFYEFcD5mGMZ5+oqWXTdSivZrjTLy3iW52mVJ4C+GAwGXBHYAYPpT7zT75pLS 4tbuP7Vbo0bNNGSrhsZOARg5UUAQa/eanbw2v9mPFHcSuQYZk3bgAWPIPHTGeeSKk1S5ln8NPqFj eSW5WAzo0aqd3y5wcg8frUc+gyahqVvc6q9neQQwlPJe1yN5xlgSxx0Axg9OtRLoOpRaBLpMWoWk aOZFUi0bakbZwoXf2zgc9ulHQOpb1jU7nTNLjube0kuZGkjUqpXjcwB6kevHuRUGr6nqcWkLeWdo be4EyqYLkKxdSwBAKsQCexz+FWZ9PvLnR/slzdQtcBlZZY4Sq5VgVypYnqBnmorqw1a9sRFLfWiT CZJFK27FQFOduN+ScjrkUn+oDLTVbme+uZI2FxafZY54YkQK+WLAjJIHbvilPiaJLK4uXsLpXt2V XgBRnwxABG1iDkn1z7VBceFmkbUGjuUCXnlkQyRZRSrFmBGeVYk8dqrw+Fr6Nbzy72xtjdmI+XDZ FUjKMDwA4znAGTzTAv2fiWC6naKayurNVEm6ScKFBTG4ZBPTPXp71JZ6/HdXMUclnc2yXOfIkl27 ZOM4GGJBxk4IHQ1D/wAI+zzsZrpHheSffH5RBZJQMrnPXI6+naoNK8MHTbuFxFpflwZ2yR2O2ZuM ZLA4B9cDn2oQFnWdRddW0zR4XKNes7yuvVY0GTg+5IH51z0+sXkXiqTSpriSG8kvFNtOZf8AR2gw CYyOm/GRjGckGt/WdPc61pmsxKXNkXjmReSY3AGQO+CB+BNQS+FlnWaB7hXtZ70XozH+8R9wbAbP TIxnGcHFJdAN28DNazBJGjbYcMuMqcdRmuNTWb5PAWgN9odrrUZ4beS4J+bDE7jn1wCM+9dYLe8Y 3gkuo2SY/wCjgRY8oYxg8/Nzz2rJi8KbfC9lo0t2HksXSSG4WPbh1OQSMn3B570dQF0W8mTxJrGj PI8sNqIpYWdizKHHKknnqP1qp4j1W7N9py2Vx5NqmpRwTMrY80ndlfoMfnWjDot3by3l7DeRrqF7 LG0sphyoRcAKFz6d89Tmqmr+BNE1SWGVLC2gkjulnlcQgmUDOVP1z19qYdC0movaeLv7IkYvFd25 uIcnJQqcMM+nIPtTb3WLOx8SeXci4jMVjJO0nmfutgPzfLnlvfFKmnNdeLl1UoUgsrY28QI++zHL EewAA/Om6v4YGs6rJdTXQWCSxks3hEfJDHOQ2eo+lLsHUzW1iZvGNhcTJcWdm2mz3DK8uUZRtIJU HAYDn8etWpfG9rCk8hs55VjtTdIYmVgyDqCc4Dd8elMi8JX8txatqWqRXMVvZy2bBLco0kbgDJO4 4bA9KSLwvrD6Dc6Ld65HLE1ubeBxa4ZVPQv83zEDjjFPoC31HXvjKSCy1Fo9MmjubaxF5CkrLiRD nngnoRyKntdXW41yximtbpLyXTzMoEo8ojIyMA9c9yKjuvCM17LO0uoJtn0v+zyFgIx1IfO71PT9 asWnh68h1ex1GbUIpHtLI2pVbcrvyfvfePp0o6i1sc3Z6i11Y22s6p/aSu+pNbj7PdbYzmTChlz9 0Y7Dmujl8WWiailukbzRvcm1MkbAlH6cr1254Jqong66XQ4dMOpRExX32wSfZiM/OW243e/XNWbH w9qGnancG31Zf7NnnM7Wxgy6sxywV8/dJ56ZoQ2WtJ1+LWJyLWEtCCymUODtZTghh1U/WqGsaxdj WrvR0gKw/wBmvcecsmGU8ge4wR2qbTvDRtdeGryzRG4ETRSNBEY/PBOQX5IJGOtO1LQbi81ptQgv Fh8yxa0dHh35BJIIOR69Klq47pGb4c8UrFpen22pRXCE6d9pF1KwbzQv3u5OenXrWrpviSDUtSNk sDozQiaNwwZWXPQkHhvas9PBTGKwhuNQWWG0sJLJ1SEqZA4A3A7jgjHvWloWlarp0axahqqXscK7 ItkHlsR2LnJyfpirum7k2Zj+M4J7GCG8hv7xZLjUIYzsnZVWNjgqADj8etN8UwyaPBpvlahfCKfU 40cCdy3lkHK5zkj9a2vEmhTa7aW9vHdpbeRcpOWaLfu2nIHUYo1/Q7jWhp/l3iW/2K6W4OYS28rn jqMDk1KGcvMddutJ1uK3vLyCJLpV0q5myj84yOcFlz0Jq9ceJLq98Cma1bydUeOSKTjmGSNT5h/D H6iuk1exn1C1SGGdIWEiuWeMvnBzjGRWY/hKAXWs3VvceXNqsRQ7l3JExXDMFz1PU80nezQ1a6ZP 4euzF4Ms7+5lklItBNK7sWZvlyeTWHdXt3qHh3Rr+S5mjbU9QhLrDKybY23YQEEEDGPrXR6do/2T w1FotxOJglv9naRU27hjGcZOPzrm7m1udP8ADWi2M0Mhk0zUIlkKIWBRd2HGB0xiqbuyVoiTUJkt fHKWU1zqJs/7N8zyoXlc79+M4XJ6Uvh/VL7UfBep3L3zs8RnFtNlfNVFzt3js3sea05dGvbjxImv 2moQRg2vkLFJbM3y53ZzuHP4U3TvDBsNN1WH7Z5l3qzvJPO0WFDMMcKD0x71LTs++o9NPkO04S6l 4MsXuru6UtbK80kBJlfjnBHP5c1iW91JefDa9uRql1PPaCby5vMeOWPaeFfoSwHqK6S00zUtO0Sx sLO+t/MtlCPJLbkh1A7AMMH8azdcsE0zwpq8a7prnUBI7eXEx3yMOgAzgVWlwVzctw91o8A86RHk gQmRfvcqMn61ieEbhW1PWLJNQuriO3mXy4bzd5sYI5OWGSpPStiKO8/sOCO0dIbkQIFaZCwU4HBG QarppF2kt5fC5hXU7mFYhOsHyIF6fLnJ/OhbsRn+LbK9NlNqNnqt3DdRFRaQxNtQvkDDL/Hn3q1c 6jPpmv6XBO+6PUwYnTPEcqrnI9jyMU2+0fX7m+W6t9atYlSMKiSWJfa2OWHzjk/SlutMm1HX9KeT 5otL3SySkY8yUrtAH6k0dhs6GlqpYxXcVsEvbhLibJJkSPYMZ44yegq1QAtFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUlLRQAlLRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRVe5uY7SB7iZmEca5YqpYgfQc1l2nizRL42whvCB d8W7SxPGsv8AulgAT9KANyism48Raba6l/Zsskxu/L8wRJbu5KZxuGAcjPGacuu6a9hLfNc+XBC5 jkaZWQqw7FSAc89Mc0AalFZSeIdNeaCBpJYpLhtsQmgePecE4GQOwNatABRWRq3iXSNEuIrfULox yzDKKsbOSM4/hBxzUepeLNE0e5S31C+8l2C5JjYhM9NxAIXPuRQBt0VQudWs7N445JWZ5U3okSNI xUdThQTjkc1G+s6etjDefaQ0M5CxFAWMhPYKMknjpjjFAGnRVSyvbe/t1ntZPMQkqTgggg4IIPII PUGrDMqKXZgqqMkk4AFAD6KyrHX7DUrv7LbNLvMXnIzRMFdOm5SRgitSgBaKiklWNCzE8AnAGScd cDqaraVqlrrOnR31k5eCQkIxUqTgkdDz2oAvUUUUAFFFFABRRRQAUUU0MDkAgkHBx2oAdRRVSa+i gvILV1l8ycMUKoSox1yeg/GgC3RSUtABRRVDU9VtNIsZ768kZILdd0rIpYqPoM0AX6KjilWaJJUO UdQwPsakoAKKKKACiiigAooooASiiqt9ewadZTXl0WWGFS8jBCxAHfA5oDctUVBZ3UV7aQ3cDbop 0DofUEZqejYBaKKKACiiigAorLGu2H269sg8jT2MQlmQRNkKemOPm6dqu2tyl1bR3EYYJKoYb1Kn n1B6UAT0UlLQAUUUUAFFZMXiLTptQjsY3kZ5GZUcRny2ZfvLuxjIrUJAGWwABk57UAOorOOsWQ1i PSTI32uWEzIuw7Sg6ndjFaFAC0UUUAFFFRsyoGZiAo5JPb3oAkoqvb3UF5AtxbTJNE4yrowZT9CK W4uobRUa4lWMSOI1LHALHoPxoAnopKWgAoopM5oAWiiigBKKKr3d1FZWst1OWEUSlnIUscD2HNGw Fiiq9hfQ6jYw31s26CdA8ZIxkGrFGwC0UlMlkSKNpJHVEQbmZjgAepoAkoqGCeK5hSaCRZY3GUdW yGFNmuoLZolmlVDM+yME/eb0FAFiiiigAopOlFAC0VGk0UjMqSKzL1AbJFQNqFml6ti11ELt13LB vG8j1C0AW6KTPrTWkRCAzBS3TJ60APoqNZY2cxh1LjqoOSKkoAKKKKACiiq15eW9hbvc3UgjjTqT 79B70AWKKybDxDY6lfS2MCXKzxAmQSQOm3GOMkYzyDWjLKsMLSuTtQFjgE/pQ9AJaKpaXqVpq+nR ahZOz284JRipUkA46HnqKbpmrWmrC4Nq7N9mmMEu5CuHGCRg/UUB0NCikHSqt7exWEImmWVlLqmI 0LnJOBwO1AFuikHQUtABRRRQAUUUUAFFFFABRRRQBT1Ef8S26/65N/I15hpAlv8ATPB+l6qEtNNJ W4t7hCWMsyE7Y2JxsyDnvnoDXqd1BHeW728wYxyKVYKxUkfUcisseFNG/sRdF+yM1ghBSIzOShBy CrE5GD6GhaP7gMXUxdn4o2n2Jolm/smTmVSVx5g9CKg8RC7TWPB0eqbPLe7Y3ZQYRpgn7v8AXOK6 VPDmmx6nFqixzm7hi8pJWuJCdmc7SCcEZ55q1qOm2eq2b2l9brPCxyVbsR0IPUEeo5o6L+uod/Mm uYreXy/tCqdjhkLHo3bHvVis2z0W1s2Vle4mKfc+0TtJs+mSeffrWlQBxviTTdT0q4uPE2l6lK0i bDcWMoVopUXAKrxlWxkjnr9a0/EEMd/pU2kwRL9o1OPawI+4pwGdvoOnvgVZXw9p630t5tmZ5ZPM aNp3Me71CE7Qfwqtf+D9H1G+lvbmO5M8oG5kvJUBA6DAYAD2ApW0sO+ph+ILO9g1ixj8MTY1WysC CkuPLlg6Bcn+LcMg9OOap6VNBcax4Pa1ilgtBHdARSn5lnHDBvU9f1rsm0PT/wDRykbxPaxeTE8U jKwTj5SQeRwOtK+h6e9rBa+R5cdu2+EoxVkbnkMOcnJz655qrk2MbweZP7a8T4z5H9pHZ6Z2Ddj8 a1/EiO/hzUQkrxEW0h3JjPCn1zVmysrfToBDbR7EyWIySSSckknkkmnXtnDqFpLa3Cs0MqFXVWKk g9RkEGoaurDTs7nG6RdX+n2vg23jvpWgvY9s0bomCoiyACACMH3qC413Wxpd28WpOssOvCzR/KQ/ ui4GCMeh6jmuol8LaTNp9pY+XMkNiwa3KTuHiwMcPnOMcdai/wCEM0PyHgFtII3uPtLAXEgzKDkN war7XkK1kZNtZ39t8Q4be41q7uwunNJ8yooOZMYwBgcY56+9ZXhq51HTdI8OTRXzfZ7u/ktpLUou zaS5znGd2R649q7e60Oxu9Rh1GSJ/tUMZiWRZGXKdcEAgHnnnvzVeLwlo0NtaW0dtIIrOYzQL9of 5HOTnrz1PXPWktBmNZajr+srHqljeW8EMd80csE0g2+WrFSpGzIboRz1qx4bfVtR1PUpbrV5Xt7G /lt0g8pAHUYxkgZyPatFfCWix6vJqkdsyXEknmOqysI2f+8Uzgt74q5p2jWWlPcvZxyIbqUzTFpW fc56nknH4U1oG5Zu5/stpNPtL+VGz4HfAJxXK2ep6k2hWfiX+01khe2eae0KLtc7SyqhABBGMck5 rryAw5HB6g1jaf4T0bS7mSeztmjLliIzIzRpu+9tQnaM98ClrqGhhjWtThsPDur/AGxrqPVZo4ri 32qFG9SQUwMjaR3JqkdY1yLT31FtWkf7PrX2QxGJNkkZk24OBnIHQgiussvDemWEkTQQOFhZmhja RikJbqVBOB1PTpnioj4S0U2j2htpTDJcfaWX7RJzJnO7Oc9eael7h0sZVxrd9a+KBZajLcWkE11t tJ40VreZcEeWxwSr5556kVjRXWq6b4W1i+tdWuPPj1do1Mqowx5wU547g/4V2v8Awj+ni585o5X/ AH/nhHlZk8z+9tJxmoZvCOiXEV1G9rIY7ybzpkFw6gvnOQAeOeeMUgMnU5dU05xaDXLi5m+zSzhI 4kEvsxJGAg/M+9M03XdUu7vwo8l1+71Kzka5iVFwzBQQwOM9+nSt698OaZqF3FdXEEjSxRGFWWZ1 LIeqtg/MPrmo7bwppFo1k0FvIpsFK2379z5YPUdefxprzB+Ryp1jXItOl1JtWkc22s/ZfKMSbZIz IFIOBnIB4IxWn/bd9b+K0sdSlubRJbthauEVre4TBwm4DKv7E9q1W8JaK1pLam2lMMtx9pZftEnM mc7s5z1qePQNPScS+XK5WYzqjzMyrIerYJxnmktLXB63NU9K82vUuDpfjt5b24lVHKBHwR9xcdAD 7YzivSaxbnwvo929+81s5/tBQLlVmdVk98A4B4HTrR1BMwF1jUtCvTHJdteQHRDeLE8agRunZcAH H1zWhoz67Pe2N9LqFvLpt3b5kjMgJLkZBTCj3yCTWonh3TEvIrzyHaeKA26lpWYeX/dIJwRUekeF dI0KZpbCF4ychVaVnWME5IUEkL+FNCsa7gupUMyEjhhjIrg7LxBq8uheH7uS/JlutTNvOfLUeYm5 hjpweB0xXf1z48FaGrq32ebCXH2iNPtDhY5O5UZ+Xr2pDexlpr19a+IWtdUlubdzJK1sFjVre7jA JCq2MhwByDTtEvPEGqDStYjvrb7DdE/aYXkHQ5wEAThgfU1uw+HdPhnWZUkYxymZFklZlRz1YAk4 qDT/AAlo2lX73tnbPFIzF9nmsY0Y9SqZwCfYU1puD8jcrhZ9c1KHVrSSHUGubebVjayFEUQhCDhB xuLDHJHHvXdVz7eDNCLlvskv/Hx9pCieQKkn95RnC574696FuHQ5u81fXYbTXb5dXlH9lakscUXl Jh4yVBVuOevBGKt6rqF3rlv4pgjvJLSPTYDEscaqd5Me4lsg8duMVuP4U0aW3vLd7aUx30wmuB9o k+dx3znI6DpxSXvhLR766kuZYJVkli8mYxXDp5yAYAcAjd+NLpYadncs+F/+RY0zt/okf/oIrP1r Ub5/EVrodnN9naa2ecuHCscHAAyp6dTxW3ZWMGnWMVnaqVghQKili2APc5NU9Z8O6Zr/AJJv4WMl u26GWORo5EJ64YEEU3uJbHO/aPEaajoWnXmrxLNc+fHdNaqrK2wZVgSOGx1GMe1Rad4k1GSHTtPu bwmW41Oe0a7KKGKx5I4xjcenSumHhzSxNZSi3dXsVK25ErjbnqTzzn1NQSeD9Dl02TT3tHMEk/2g /vnLLITnerZyDn0oAzZ7/U7DVdO0K41QTNfXMn+kqih0jVcqhHTcfXFUZ/FGqWE97pEtwXkTUYbW G9ZBlUkGeeMbgOOnNdK/hnSXsYrM277IJPOjk81/NV/72/O7P40s3hnSbrTprCe2MkM7+ZIWcl2c dG3Zzn3zQBzJW7sPE/ip49QkaeLS45IpnVSykBj6YPI9Kkt9R1i/1Dw5bf2pJBHqGnPJPsjQsXAB yMg46/8A1q3YvCWkRPcvsuJHuoRBM8lzIxdBxgnNSQ+GNKgns5ooJFexhMNuftD/ACIeo68/WgRz ln4i1iTw9pks85YPqL2l3dqg3hFYgNjGBnABOOK3PC8uqzDUJNQuJZoVumS0aSNV3RDo3AGfrWbr PhVLe0tLXTNMe5so7h55oo710mDn+JHJ9c5GRWn4c0u405Z3c3cUMuNltc3JnZPU7jnH0yRQN9Cb xVq8mh+G7zUYkDSQqNuRkDJAyfpnNZjXmpWPiTTNPa/lubbU7Z8sUTdDIoB3KQOnPfNdLdWsF7bS W1zGssMq7XRujA1Qs/D9hYsDCkpKReUjPMzNGvopJ4H0pWAyPhzDInhZGe5kl3XE2FcL8v7xumAO tW/HZlXwVqbwzyQukOQ0ZAPUcfStPSdHstEtPslhE8UO4ttaRnwScn7xNSX1lb6jYzWV3H5lvMpS RCSNymm9RbHHS2ly/izQ4I9QlikOkSZnCoXx8vTjH6Gk0zxJqmo2ei2LXAW5vROJJywRn8skDB2k bj34rpYvDOlQ3VvdpFN51rCYInNxISqHqOTz9ary+CtBm0yLTjauIYJTNERO++NyeSrZyPzoWwdS 14eXVY9OMWs3Nvc3UcrAyQnOVz8u7gYbHXipNZe8TTmawXM5YAAY3YzztyQC3pmp9PsLfTbRLW2Q pGv95ixJ9STyTTdQ0621O3WC5WQqjiRCjlGVh0IIIoY0Y1peXzWWqRnULkzQRB4vtNuqTRHBJzgB WBxwRVqK7u2vtGZpwY7yAmWLaMFggbcD161bs9JtbQTbfNlacYkeaRpGYdMZJ6e1VoPDGm291Dc/ 6S81vnyWe5dvLBGNo56Y7UdQMnTf7Ug0OXUIdQjSO2ml2W2wFHUOc7j1DfQ1d8QreDT21SC/aOOJ UkW2khR1zkdcjOefWp4fCmlW21YY5xCH3tCbh2R2zncwJO459aNbi1LUUk023s0FvMFD3Ty42DOT hcZJ49qXYO5V8R6reQ6tbaZam6iEsLTSS2kIlkwCBtUHgdc5OaZaavq39kMtxG6XDXS28M9xD5Zc MeHKeo544FbWoaTa6n5ZnEiSRHMcsUjRumeuCpB/DpUcWh2MdhJZMJpY5TudpZmdy3ruJyPw6U0A y2stVt7x0l1Q3Nq8OFaSNRKkmeowACMe1Z/g6yvotLhmn1WW4i3SjymjUDPmNzkDNatlpFrYTGeN p5Ziu3zJpmkIX0GScfhUUGgWVvdfaI3ukAcyLCLh/LVj1O3OMe3ShAa1cJruuanZ3c9xaX7TJDqM NvsjRRFGrEBkckZLc546cdK7uufu/BuiXkty81rIftUollVZ3CmQdHC5wG4HNLqBzupatrsUfia6 j1eRBpF0hgj8pMFSASrZHI5/+vV671K71ufX7OK8ksk060UBY1Ul2dCxY5B4HTtWxJ4U0aSG+he3 laPUGDXQ+0SfvCOB3yPwpLrwnpF5ci5khlWXyfIdorh0MseOFfB+b8aN1YE7O4vgv/kTdI7f6JH/ ACqzrcl9HZL9h3GRpAG8sKZNnfZu4Jx61Pp2nW2lafFY2aFbeFdqKWLYH1OTTNQ0y21NY/tIkBhf fE8cjRsjYxnII9abEtDFS/vl0XUmXUJWntSGTz7cJKg64cYwc88gY9OlaDz3I1yOBpy1vNZs/lbB 8rAgZz171PbaPZ28E8AWSX7QMTNM7Oz8dyTnHt2qCDw1p1vdC5H2p5/LaISSXUjEIR90c9P689aX Qa3MbTX1Oz8OQ6o1+rRRM261WMbDHvI4P3t/vnHtWjr0V7byxX0d+TGlxGFt2iQgZYAkEjNTWvhX S7PyxCk4iibckLTuyBv720k85pNUg1LULhLJLRI7VZkka4aYZIUgkBQO/SnfUSVkUdd1e9Gtrpdq 17BGkAmkls7cSuxJwANwIAHU8elPtNU1a6srS2nDWl1c3DwefJEFYoqlt4Q5AJAxg8ZrW1DR7XUn jkkM0U0eQs0ErRuoPbI6j2PFN/sKx+wCzKzNGH8wO0zmQP8A3g5O7P40IZXe01WK01CKbVDLGYcw S+WolQ4O7dgYI6Y49aZ4VtLy30WykuNTkuY2tI9qPGqhPlHcDJ/Gr1npNtZCXyxLI8wxJJNI0jMP TJPT26VXtvDtlbbhG93s2GNYzdSbEUjoBnH49qAOe064tLbxD/aVvZTQ/a7preR1t2WMx9FO7GD8 4zn3rpNTH/E30c4589+cf9M2ofw9pz6VHpbLcfZYiCi/aZN3HT5t2T9Cabd+HbC+uluJzeGRPuFb 2VAvGOAGAHFHQCp4itLy41nRvs+oyWmZpBhI1bny2OeQewx+NN8QaW1zYafbzTmS5W5TZdFQrK2c hhjp2rVvdJtr6CKGUyr5JDRypKyupxjIbOenHPWojoFi9tDBI106wy+arNdSbt/u2cn6dKEBkafd 2q6jqOozRx21xFaotywTlXBbPH5EfhTtN1HUv7U+yTPfGOa2eVXuoo0IIIA2hecc9G56VsS6Np8s t27W/wA96gSdgx+cDp34PPWq8fhrT47tbwm7kuFUoJHupCdp6r16dPypMEYCX2vJaLcSasGP2Nrt wLdQCVYAKPYg8/TjFS6hrWq3OrX8Fo99brZMI0FtaLKsjFQxLk9uQMDH1rcXw1pi26wLFKY1haAA zuTsbkjk0lz4esppRMHuoZCio7QXLoZFHQMQeT79femxIuaXcT3emW9xdQG3nkQGSI/wt3rnviHF I/h+ErcyR4vYAQgU5zIvPI7V09vbx2tskEKkIgwoLEn8zyaqarpFlrVulvfRNLEjiQKsjJ8wOQeC O9D3BdjA1XWdQ0XX7iP7U9zbwaPJdCJ0UFpFYDOQPTNS6Ydekntrya/t5tPu7Ul0aQFi5XcGTCjj rxnpWw+h6fJqS6g8LvcCE2+5pGIMZ6qQTjtVbS/CWjaMZPsVvJGHUqFMzsIweoQE/L+GKT1TQ1uc x4Z1OePR/C+jQStb/b0nd5VA3AIx+Vc8ZJI/AUmmS6rp9hrRsRLeyprbibZsE0ke1c7QRgtj+tdM 3g7RG02109bWRIbN/Mt2Wdw8RPXa+dw/Olh8JaTbh1hS4Rnn+0M4uZNxkxjdnPp+dNsS0H+GNSj1 XSFuI7qW6/eOrGaPZIhB+4y4GCOlV/GV9e6dpEVzZXDQyfa4Y2woIZWcKRyPQ9q2LGwt9PhMVtHs VmLvk5LMeST71Fqmk2Ws26219G0kSusgUSMmGU5B4IPWh73BdjmdUutYk17XLO31ea3gtNPS4hVI 4yVc7uMkdPl/+vXSaDfSajoGn3s2DLcW8cjkDAyVBPFRSeHdNlurm5eKXzrqEQTP57/Ogzgdfc/n VvT7C302yis7VGSCFQsas5baAMAZPNAFsUtIOgpaBhRRRQAUUUUAFFFFADSQoJJAA6k1Tt9X066a Rbe+glMQ3OFkB2r6n296p+LrS8vvCuo2+ngm5eE7FBxv7lfxGR+Nc3qUjeIdAuZ9K0G6gv0tUSQz RGJiqurGFc4LZAPI49+aQzrP7d0kwzTDUrXy4Mec3mjEeemeeM9qp3Xi7Q7WW3i/tG3kaefyRskB CtjJ3HtgfzrmL2Kw1TQNXvrDRdTS7m0827m4jlLlv4UCHO7B7gYHrV3U7UQWfhi7h0+Xy7e5ja4E Vud6DyyuWUDPUgdOKfUXT7zfXVooJdSnm1K0lt7RVPlxkB4eDnec9z06Vi6br1/qkWm6gusaVDaX m3dbuMyKx/5Zqc8nB7jIPbmmxLJHr3iyZrO5WOeCLy2+ztiUiMggcfMckDis8wz/APCHeE4TYXfn W13bmZPsz7owoO4sMZAHrQt/uDodvPqun21ytvPeQRzOQqxvIAST0GPU9vWk/tbTxdiz+2wfaC5Q R+YN27GcfXHauTtJPI1HVdH1bRrm7kuNQNzbSeQWikUkFSXxhduADnp2rOvDdzXduw0q9ga210Sy QQ2rFNnzDzN+PmJyMkHA9KW4d/I7TT/EWl6jc38FvdRk2MhSUlgOgBJ+gzjNWYdX024jmlhvYJEg P7xlkB2fX0rh7y01H7N4mtrewunnbUUu1RYyoniGwkK/QkgHjOastb6Rqun31/BpmsW5uEijmnZZ BMGDArtU5J2nkkDHbmjoD3O0tL61vVZ7a4jmVDtYowO0+h9DVd9c0hEmkfU7RUgfZMxnUCNvRjng +xrN8JtqXl3sepFbjZOBFeiAxG5XaPmK+o6ZHBxWXrvh66utfvrC3iK6fr1sDczAcQSJxuHuRt/I 03oCNzxDrP2DRb2exubZr2C1a4jjc7tygdcAg4PrU2k61Z6nCkSXlvJdiFXmijcFkyPTORXM+Rql z4D1OfUbOX+0ZbNrVYkQs7BAVBAAz8xyfoaqXun3lzd2cWnWdxbyPoEtuJPs7IqSEDapOBtPB69K Bb2O5t9VsLu4MFvewTShd2xJATjpnHp70sGqWNzcGCG7hklAJKK4JwDgnHpnvXHwQS6o3hg21lPb T6aSbvfCU8tRHtZMkDOTjpn1qna6fq3kT6fpbzz2c9jOIFu4GjmsXOMR7yBuB6eoxRsPc7u21XT7 y4aC2vIZpUG5kRwSAe+PT3p13qVlY4N3dRW4IJHmOBwOp+nvXK+F/sN/e2dz/YuoWuoWluYpHuvM CxZxlVJOGyR26VJ4wt5zfrc2E1xb30VowX/RzNBcqScxOAODnocg80PQFqdIdV07fKn2633QoJJV 8wZRT0J9BWJfeJlsvEWno17aLpN1aSzGct3Xbghs4IOfSsmdrm112e4utNuEa+0NYlSCFnVZBuym QOOo6kVX0q3a3PhS6vtPuPJttPkhlDWzMYpDtwCuM9jzR1/rzEdfc6pBMlhJZatYrFczDaWIf7Qu DlUII5/OrUuq6fBdJaS3kMc7ttWNpACTjOPrjtXB/wBlPp1tpuYDbw3HiPz7aAjBijIbAx2z1x2z UsNtC2o32j61o+o3Nw+oNcW0iF/JkUtuVtwOF298+n4ULUb0O2k1WwguVtpr2COd2CrG0gBJPQfW q+m6/p+q397ZWs6PLZSeXIueScAnA9OcVzWmlorq/wBF1jRbi7uG1A3MEvklopFLZV9+MDb06546 VpeHEmtfEfiGGa2mjM12s0chjOx0KKOGxjqOlCE9DXa7P9uC2F/bBFgLPbH/AFuc8PnPC9ulS22p WV5K0VtdwzOo3MqOCQOx47VzmrRMfHQmNlcywf2RLE7xxNhiWzs3AYzjpzTPCceoWmqfZd8t5pot QYbi5gMU8HPETEgbvX1FKOqG9DpbzVdP09gt5ewwMRuxJIAcZxn6Z71Zknjihad3AjVd5bPG0DJN cP4xFxPfaraR6dcgzaWUint7cyG5bk7C2CFA/AnPXtXR2EB1HwjDayLJCZ7LymDoVZcpg5B5FDvZ tbhpdJlXRtV1TxFZDVLL7Pa2cxP2ZJoy7yKOAxIIC59Oa0bS/uItF+2atCtvPGjGdEyVyP7ueue1 YPhK+fQtDt9C1S0uobuxXylKW7yJMoPDKygg5HbtV7WXn1SSx0ox3VsLhvNmkSIsEVTkAtgqCTjj 2psXqSeEtffxDpbzzwfZrqCZoZ4D1Qjp+Ywatanqf2a8tNPhw13eMdgPRFXlmP04/E1z0Fvd+H/i A5UXt5Z6vAPPlFvlYpl4UkqABkcZq3qETxfErSLp8iGSymgU9t+Q2Prj+VHVD2NQalHDf3xudVsv s1siFkyFeA9y5Jxg9uBVm11jTb25a2tL+3nmRQ7RxyBmAPQ4Brj9UgnfWPFzJY3LLcaakcTC3YiV wpGAcc9R0qJbK6N/oaWlncQP/Ys0Bk+zsqxSMo2hjjg5z1pXCx2seqWNxcNaW99bvc4JEYcMeOM4 zyKyfDHiI6jo8FxqtxbQ3U9xJDGgOwOVYgbQTknAqh4WuYp7bTbe60K5h1HTIjHK80BVYsDBKtjD Z9qxLWC7tvC2k3Ethdr9i1tppk+zvvWMs3zBcZI5HQU7AtT0EanYMs7reQMls22ZhICIj6N6GsC1 8TSXWs63arf2SWllbo8NwRhUZgfv88gH6VzV2l/Jdarew6beNbrrMF08RgYGaAJgkDHODzjrx0q9 M/2zVvFN1Bp92YbzS0WFjaSL5r7WGACOvIpPa4Lex1qa3p9rbwC/1WzErQCVm8wKHGOXAJ+7VldU sGs47wXkJt5ceXKHG189MHvXHadbSDXPC8s1hc7LfSnSVntmxG2BgHjg8Hisy2WWw8P6PNJaX0c9 nq0siQ/ZnOVJbkpjOMHggHFNgj0az1Kx1Dd9ju4bjYcN5ThsfXFYJ1fWbjxle6Hby2cUVvapcLI8 DMTuJGCAw9OtL4Mew8vUGtpnae4uWuZ45IHh2FugCsAce/eqkc5s/iTqV7NaXv2Z9PiiWVbSR1Zg xJAIBzxR1DozQ0fxFNcaxfaJqkMdvf2SiXcjkxzRHo4z0+hrR/t7R/LmkOp2oSAAys0wAQHoT6D3 rjr/AEbV9cv9c12C0ktjJYC1sYZPlklAOWJH8OegzzV3RrXSddYytomowTNZG0uHvBIuxT1QBjhu e46UdPMOvkdU19at5Ucd5D5lypMGWB8z3AzyPpXIx+L9ZbwJqXiBls/Ps5ZUWPym2sEfbz82cmr3 hG11C3gYatEwbSw1nbtgt5qA/wCsHfkYH4VzUVvef8Kp1ux/s69+1TXM5jh+yvufdJlSBjJGO9Lq HQ6bU9d1jQNJh1m8jtr2xwrXQgRo5IVbHzAEkMBnnpXQS3Sf2c10k8ccbRb1lc/KoIyCfauV1+S6 1vwoNB02xunubyFIZHlgeOOBcDcxLAZxjoM10NxaCx8MvZorSiKzMQCqWLYTHA680Sdk2C3RHba1 ZQWVq1/q1k00sRk8xXCrIB1ZQT0pl34r0a0jsZTfQyR6hKIoHRwVPqc9MCuU0q2lX/hCvO026/0S GUT7rVv3RK4GeOOagtrW6gtbKY6beCO28QyTOgtn3CNs4YLjO36VTEtjvrjV9OtJUjuL6CJ3xtVp ACc9PzqN/EGjxzm3k1S0SVX8soZlyGxnGPXFcfcQRHWtY03WtI1G6j1GYS2rwCTy5FwMKxU4Ugjv 2q7otmq614mln06RQWjMLPbt82I8HaSPmOeOKm+gzok8QaLJIkceq2bO6GRQJl5UdT16VNb6tp93 ZNe299BLaqSGmSQFQR15rgbCwkTRPBsb6Xch7a8LzobR8xj5uWGOOo60t1bagi63Pb6ddyRxa1Hd GFImRp4gMNs6bvXj0pvQSO9i1bT7iCW4hvIHhhJWWRXG1COuT2rn4/FElzrusWseoWKWdpaJLFct 92N2z9855xx6Vj6naxz6Y+raJo+oeWb2Ce8SYSebcoh5wjcnH05x3pNQc6hqniS6tdPvGhu9ISOJ jaSDzHGeMbc55FHca6Hatq9lZWkDX+oWys8QcvvCq/AywyelRT+ItNt9atdJa5jNxdRmVPmGNvbn 37VyN8LmS1htBpl3Gz6EIlmitmZ5H2/6okjCYIzzgn1qXT4rpNS8M3DWV2i/2U9sXMDZilwMbuMr 06nFAI7NdV09r0WS3kDXJJAiDjdx149qmubqCziMtxMkSA4LOQBmuE8N28Mz2Gn6nouo/wBq6bcM wkkMghU5P7wNnaQQenf0rZ8WvdWeo6NqiWs13ZWlw/2qOBC7KGXAfaOuD6CjYEbi6tp7WYvFvYTb Z2+aHG3Ppn1qNvEGjLFHM2qWixzZ8tjMoD46455xXKasohGmatZaLeJpsd3LJcwQIyzHeuPNKD5u vbrVaews/tWgzafot7HaPqj3EnmwvI3KYLsCCVBPrRuB08PivR7vUpbC1voHkSATeYHG0g9MHv61 T1DxMNI8OWt3Jf2d3cXMyxpLG2I23NgsOegHv2qJYWsvHOot9hmW2uNOjSFo4CUypbIyBgHnp3rE WC5T4eaJa/2beedDqCM8Qtn3IolJJIxwMGgNjqtIvL+TVJre71bTbuNYy8cVupEm0nhm5OB2rSh1 bT7i4aCC/t5JUBZkWQEgDqcZ6Vy+rWl7d+LNS+w28yNPojQxTmIqhfdkKWxjNM027jvdFQjw1ctq NhYPA6TwGPBC4KK38QYjtSvoFjpm8QaSILicahbultH5smyQEqvrx296bZ+ItMu9Ih1RbqJLaZcq WcemcfXHauJs4rq51SN0sr7bNoUluN9o0SRPx+7GRkAdOevqaWJ57Ky8N31xpuovY29m1tcxwxSL JBJgYYoMEjgjPvTA7xtW05LaO5a+txBKC0cnmDawHUg1UutYWzvLAyOj2V+wjilQ/dcjK/UN61y9 1pcENpZto0V/o8iCaW3Z4WmRtx5SVTkjd1x2qxryXl/4Y8PW0tqtrfz3tuTDGOI9py2PQACgR3I6 ClqlaahHdy3UawzxG2k8tmljKh+M5XPUe9XB0oGLRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGTJocM2pi+muLiXZIJI4HYGONwMAqMZHU9+9a1FFABRRR QAUUUUAFFFFABRRRQAVTurOK8jCTA/IwdGBwUYdCDVyigBB09aWiigAooooAKKKKACsrVtDh1WW3 uGubq1uLYt5U1vJtZQeo6EEcdxWrRQBQsdNSxUkSyzzP9+aZsu3+H0GKvUtFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVVa0ia+F0y7pFXahPOz1x 9fWrVFACUtFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf//Z --_004_27D27ED4408AA64998F40FB212076767DC282548hasmsx109gercor_-- From nobody Tue Jul 30 13:42:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65589120089 for ; Tue, 30 Jul 2019 13:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 22S7xiTstN6U for ; Tue, 30 Jul 2019 13:42:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D483512004D for ; Tue, 30 Jul 2019 13:42:03 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D094E54802C; Tue, 30 Jul 2019 22:41:58 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C0914440041; Tue, 30 Jul 2019 22:41:58 +0200 (CEST) Date: Tue, 30 Jul 2019 22:41:58 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20190730204158.w7b7dviwk55cxfce@faui48f.informatik.uni-erlangen.de> References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> <20190725143632.5fktdhifgmtyx2gk@faui48f.informatik.uni-erlangen.de> <27695.1564184021@dooku.sandelman.ca> <20190729220921.j4y5oqtoj4hkfekg@faui48f.informatik.uni-erlangen.de> <18051.1564454793@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18051.1564454793@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 20:42:07 -0000 On Mon, Jul 29, 2019 at 10:46:33PM -0400, Michael Richardson wrote: > It's not about keypair, it's about what IPsec would call the SPD, which is a > way to select which traffic goes into which tunnel. I would also have > expected it to be able to select based upon VLAN tag and destination ethernet > type, but people said that wasn't so. I think my reference was more to what chips can do as to what necessarily existing standaerds may say. There is this one issue of having an 802.1ae capable switch port connected via a hub to multiple host, in which case you could imagine to use a different set of keys to each host but the public vendor documentation i found was quite inconclusive whether this actually works in todays products. Your reference to IPsec is also another big question. Right now, there is all this convoluted, 802.1x and AAA server MacSec session setup mechanism. Which natively is asymmetric, and AFAIK, the extensions to make it symmetric whee either done only very recently or are still TBD in ieee. One solution is just to leverage all of this and just declare that nodes need to use and trust their ACP domain certificates - and be done. It would just be anothrer parallel ACP secure channel mechanism beside IKEv2 and DTLS. Personally i would love a simpler mechanism, but there is a different simpler/nicer architectural solution and a simpler/nicer programmatic solution: The simpler architectural mechanism is to tie MacSec into IKEv2. But who would be the critical mass of people doing that work. It's not easy. The simple pragmatic solution is to put ACP on top of some ethertype like EAPoL and exclude it from 802.1x, build normal IPsec ACP and then have small new ASA that simply auto-instantiate existing MACsec for the data-plane. > I would love to be told I'm wrong. > I can see if one was building the minimum viable solution that can deal with > state-level attackers on point to point fiber runs, that just encrypting > everything works well. The fiber runs in my apartment complex are in rooms open to the public. No need to hire overpayed federal employees to plug a fiber snooping device into them. And the city wide fibers are either on open poles or in digging distance of shovels through somebody elses garden (learned that from comcast workers that dug up those gardens too to find the shovel made fiber cuts). Sorry. not directly on-topic but hopefully entertaining. If we want the least overhead solution, then its the last option i mentioned. We did program that in tcl in a week as small ASA (send random generated PSK to direct neighbor, auto-configure existing MACsec to neighbor. Done). Of course this expects ACP to already be in place, and if you can't exclude ACP from the MacSec encryption you have to have a bit of logic in the ASA to avoid shooting yourself into the feet. Cheers Toerless > > if ACP can be separately encrypted from data-plane, but as long as ACP > > is responsible to manage the encryption key, it can equally encrypt > > both ACP and data-plane. Its just that right now, ACP is not optimized > > for fast reconvergence, so a data-plane could converge faster and then > > it might still need to wait for ACP. But thats solely a matter of > > routing protocol and aliveness parameters of ACP/data-plane. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Tue Jul 30 14:08:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475AF120143 for ; Tue, 30 Jul 2019 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hfWOiHPkgG31 for ; Tue, 30 Jul 2019 14:08:05 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A164C120105 for ; Tue, 30 Jul 2019 14:08:04 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C0C8554802C; Tue, 30 Jul 2019 23:07:59 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AE21F440041; Tue, 30 Jul 2019 23:07:59 +0200 (CEST) Date: Tue, 30 Jul 2019 23:07:59 +0200 From: Toerless Eckert To: "Mendelson, Tsippy" Cc: "tte+ietf@cs.fau.de" , "anima@ietf.org" , "mcr+ietf@sandelman.ca" , "Michael.H.Behringer@gmail.com" , "kwatsen@juniper.net" , "Ruan, Xiaoyu" , "Jayanna, Prabhu" Message-ID: <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 21:08:07 -0000 Ideally i would like to negotiate you into liking and accepting the text as it stands, and if then - if you are interested - to help write a small followup document amending the solution space to other pledge IDevID formats (e.g.: without these easy identifiers). The reason for me saying this is that the authors and i think the industry well understands the workflows in which these device identifiers are also communicated via sales integration, appear on printed labels and all the like. So we feel safe that we have a rock solid solution when we do have this identifier in the IDevID. >From what i understand (and please correct me if you are coming from a different angle), you may be able to reduce cost in manufacturing of low-cost and/or constrained device by not having to have IDevID securely installed with such serialNum, but instead just having a self-signed certificate or maybe even only a self-generated key-pair - and then for example just using a simple registration process at the manufacturer to remembrer the public key pair there - manufacturer doesn't need to create any other device tracking space other than the public key. Not good for humans, but good enough for automated mechanisms. This is i think what we discussed during a BRSKI/ACME side-meeting last week (see also notes sent by Owen and I). I think it is perfectly feasible to adopt BRSKI to support these type of environments, probably with only few changes, but it would be a lot easier to conclude on HOW to do it through the aforementioned separate followup document. For example, i am not sure if TLS can authenticate just with public key pair, or not (if not we would always ask to create self-signed certificate), then we might need to amend the voucher format (not sure), and ultimately, there may need to be some form of standardized sales integration signaling so that the owner learns about the public keys of the devices he bought. E.g.: something like this. Cheers Toerless On Tue, Jul 23, 2019 at 09:26:54AM +0000, Mendelson, Tsippy wrote: > Hi, > > Sending again to wider ANIMA audience - as I received no response. > > Thanks, > Tsippy > > > > > From: Mendelson, Tsippy > Sent: Sunday, June 30, 2019 11:18 > To: tte+ietf@cs.fau.de > Cc: Ruan, Xiaoyu ; Jayanna, Prabhu ; Mendelson, Tsippy > Subject: Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 > > Hello, > > We have identified a reference to an old spec in BRSKI draft draft-ietf-anima-bootstrapping-keyinfra-22. > > The draft refers to: > > [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, > standard/802.1AR-2009.html>. > However there is a later spec: https://standards.ieee.org/standard/802_1AR-2018.html > > The specific quote from 802.1AR-2009 that we would like to ask about is in section 2.3.1 "Identification of the Pledge": > > > The following fields are defined in [IDevID] and [RFC5280]: > > > > o The subject field's DN encoding MUST include the "serialNumber" > > attribute with the device's unique serial number. (from [IDevID] > > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard > > attributes) > > In 802_1AR-2018 we could not find that the "serialNumber" attribute MUST be included rather we found SHOULD: > [cid:image002.jpg@01D54150.D86DC7C0] > Here it says: An IDevID certificate subject field shall be non-null and should include a unique device serial number. > > We would be happy for a clarification. > > Thanks, > Tsippy > > > > > > > Tsippy Mendelson, > Manageability Chief Architect, > IP Technologies Group, SecIP - CSE FW Architect > Intel Israel Design Center > Phone: +972-2-589-2468 > Cellular: +972-54-7885061 > > > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jul 30 15:23:42 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6E1201C9 for ; Tue, 30 Jul 2019 15:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TmtHjk-pX9jO for ; Tue, 30 Jul 2019 15:23:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614A81201CB for ; Tue, 30 Jul 2019 15:23:39 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 906DF3808A; Tue, 30 Jul 2019 18:23:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5042914; Tue, 30 Jul 2019 18:23:37 -0400 (EDT) From: Michael Richardson To: Toerless Eckert , "Mendelson\, Tsippy" , "anima\@ietf.org" , "Ruan\, Xiaoyu" , "Jayanna\, Prabhu" In-Reply-To: <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 22:23:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > From what i understand (and please correct me if you are coming from a > different angle), you may be able to reduce cost in manufacturing of > low-cost and/or constrained device by not having to have IDevID I didn't get that all from the original poster. I think you are jumping to a conclusion that is not supported by text here. They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather= a SHOULD. And, that's not the point at all, really. IF you want to do BRSKI, then you MUST include a serialNumber in the DN. 802.1AR-2009, has section 7.2.8: 7.2.8 subject The DevID subject field shall uniquely identify the device associated with the particular DevID credential within the issuer=E2=80=99s doma= in of significance. The formatting of this field shall contain a unique X.5= 00 Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers. In the case of a third-party CA or a standards certification agency, this can contain the manufacturer=E2= =80=99s identity information. The subject field=E2=80=99s DN encoding should include the =E2=80=9CserialNumber=E2=80=9D attribute with the device=E2=80=99= s unique serial number. Note lack of RFC2119 language (or a reference to it). So if the 2018 has "SHOULD" here, then that's a strengthing of the language, not a weaking. The first paragraph does have weasel words "any other suitable unique DN", but I really think that a serialNumber DN attribute (as opposed to the serialNumber certificate attribute) is needed for BRSKI to interoperate well. If someone has a 10 million devices in the field which can be field upgraded to run BRSKI (while still in a not-yet enrolled state in a box), then let's talk about this. Maybe it's actually 10,000,000 TPM devices with IDevIDs already generated, but no serialNumber in it. Getting the JRC code right to do other things can be a pain, but it can be done. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Aw2kACgkQgItw+93Q 3WVOxAf/Z6n93mycqPbAZ2aX+NWTEAWbRPJOX2lpGrIt41IGZowuwurnmpJR1LNR DLIgS6xXY5/6koqcv2s24Wh/gZjpij28nJDGal/O8tQYvdlJqo+arSscciN1oaly hftSVdVVy4DH45wiAOkmWGG258tvD004KteWcRHwJuFmKiZe6Nk5tnjdT0x/HhkN NA5IEs4JWtbo5WXu7j38aDpUri0OUBPio3JD10y2lKqjnsY2f0OZYLv9BsH4Yen6 StGOzjxIRJ+ElWWLLpH8WwgzSAHIGf/47N6MLGDQqw2RLW49xsMqlUfs88VmWc/j c49bKT9evdMNXrpGOG1pvJEQUgG3YQ== =DEOL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 30 16:11:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDF12010E for ; Tue, 30 Jul 2019 16:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 p4o3K5NAj2fu for ; Tue, 30 Jul 2019 16:11:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCED12007C for ; Tue, 30 Jul 2019 16:11:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7711B548342; Wed, 31 Jul 2019 01:11:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5F144440041; Wed, 31 Jul 2019 01:11:36 +0200 (CEST) Date: Wed, 31 Jul 2019 01:11:36 +0200 From: Toerless Eckert To: Michael Richardson Cc: "Mendelson, Tsippy" , "anima@ietf.org" , "Ruan, Xiaoyu" , "Jayanna, Prabhu" Message-ID: <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> <31027.1564525417@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31027.1564525417@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 23:11:43 -0000 On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > From what i understand (and please correct me if you are coming from a > > different angle), you may be able to reduce cost in manufacturing of > > low-cost and/or constrained device by not having to have IDevID > > I didn't get that all from the original poster. > I think you are jumping to a conclusion that is not supported by text here. Yes, i was elaborating about why one would want an IDevID without the serialNumber and what would need to happen to support that. But i also said this should be out of scope for the current BRSKI document. > They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a SHOULD. > And, that's not the point at all, really. > IF you want to do BRSKI, then you MUST include a serialNumber in the DN. Agreed. > 802.1AR-2009, has section 7.2.8: > > 7.2.8 subject > The DevID subject field shall uniquely identify the device associated > with the particular DevID credential within the issuer???s domain of > significance. The formatting of this field shall contain a unique X.500 > Distinguished Name (DN). This may include the unique device serial > number assigned by the manufacturer or any other suitable unique DN > value that the issuer prefers. In the case of a third-party CA or a > standards certification agency, this can contain the manufacturer???s > identity information. > > The subject field???s DN encoding should include > the ???serialNumber??? attribute with the device???s unique serial number. > > Note lack of RFC2119 language (or a reference to it). > > So if the 2018 has "SHOULD" here, then that's a strengthing of the language, > not a weaking. > The first paragraph does have weasel words "any other > suitable unique DN", but Ok, i currently can't access the IEEE standards, so i can not compare myself. My reading of the OP was that it was a weakening. > I really think that a serialNumber DN attribute > (as opposed to the serialNumber certificate attribute) is needed for BRSKI > to interoperate well. Agreed. > If someone has a 10 million devices in the field which can be field upgraded > to run BRSKI (while still in a not-yet enrolled state in a box), then let's > talk about this. Maybe it's actually 10,000,000 TPM devices with IDevIDs > already generated, but no serialNumber in it. Getting the JRC code right > to do other things can be a pain, but it can be done. Right, this was my question to the OP as well. I was guessing its more about minimizing cost for future built 10 million devices. Today you would need to burn-in during manufacturing identity elements such as specifically the serialNumber, so you need to devise a protected burn-in process. If you just et the device generate a public key pair and you simply capture the public key during manufacturing, maybe that is a significant simplification when you talk 10 million devices. Just guessing. In any case, serialNumber is a lot more useful when humans are involved, but they may become less relevant when everything is automated. Cheers Toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jul 30 19:18:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6A1200A4 for ; Tue, 30 Jul 2019 19:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 duRaC3u0IqZe for ; Tue, 30 Jul 2019 19:18:10 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F3312004E for ; Tue, 30 Jul 2019 19:18:10 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id r1so30897435pfq.12 for ; Tue, 30 Jul 2019 19:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=66pjT5Madz8DdmWMyw7EgqidntlWceBK+knaV6Xg2Rc=; b=HrBbIJUo4pXBklJZnmXQEhjhBG9iY0ukjzkSFOk3r2BQLIn8jEqKF3PRzBFHP0gbGH Cx2a7qw84fbmHYfyIWK0JmYaBkZvIGZnZURtNDmdOAiOcf4IiWj3wBVKJWWY5Cv6cCNA mx+j0qResVkhPVtM1aXjMGJeNQ19X46z+1/iw0+cMhA5dqM8Cv1OGHikl6Q/YLd3SJq8 HAJGQC46DSbmvQsxzwMuo1cXqtXzdVayP2g8KpJiNMr6mqdiPAT9d2PV24S1whRMRule HkqrVerULSWSGOrVsiBcQHJc6Np4k5ct0C0Slvm0KDasUG2bMoXAxLfK6BZgn30JB10t VWCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=66pjT5Madz8DdmWMyw7EgqidntlWceBK+knaV6Xg2Rc=; b=Ovyj1XUICCMPpLG0jxwz7uLk27NqX5EqGyeVHTIDFczGWkDeiqmFVdbDZsiX7q8YzY iVKUi/JKr2EU/s4d4P/aQkv5zBoMp1Ew5cxyuK4rSln4k+IsCpVor7biED0o/1dOp4Yh ap4YNnN2pKdtGSbeivdigl6kk1hJ0mJJNbGN9mqo4F79Ly0WvkQ/tFd6Y16PLoh/WfmW VvYjEe84Wdlhr8p4GEo1BXIEsfUi6J30p5eScteVdA+HLkoHm/1VcCdhksuGFFDBlQ5z e10fSG4rtsoUv+UkMRxWZcL5ScIoOB9Fa3xR9TdKjrGJswpPuB0TaAisF1NIFCgrLuJu ZNiQ== X-Gm-Message-State: APjAAAUv1xzJ476h5DkuGU5Lh6KlWEvxJ4A/jH+NWxg6SgHAtYxUe0Sx X8EFW6COlWhWaghXYBa+j8Q= X-Google-Smtp-Source: APXvYqzpnwc1HD3FJicCFJsc9LFgCRqrrKQygY5sYlVHBDEQbcGScTBQxizjnjriFxAWDQB8oJM3ig== X-Received: by 2002:a17:90a:a410:: with SMTP id y16mr438108pjp.62.1564539489559; Tue, 30 Jul 2019 19:18:09 -0700 (PDT) Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id q8sm160608pjq.20.2019.07.30.19.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 19:18:08 -0700 (PDT) To: Toerless Eckert , Michael Richardson Cc: "Jayanna, Prabhu" , "Mendelson, Tsippy" , "anima@ietf.org" , "Ruan, Xiaoyu" References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> <31027.1564525417@localhost> <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> Date: Wed, 31 Jul 2019 14:18:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 02:18:13 -0000 Let's be clear in the BRSKI text that our standard makes this a MUST *even if* it is not mandatory in the IEEE standard. Of course we can do that (and not including the serial number seems very sloppy), but we should be explicit that our requirement is stronger than the IEEE. Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think we care, because our model is that nodes containing management smarts such as an ASA need to join the ACP, but managed nodes themselves do not. Regards Brian On 31-Jul-19 11:11, Toerless Eckert wrote: > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: >> >> Toerless Eckert wrote: >> > From what i understand (and please correct me if you are coming from a >> > different angle), you may be able to reduce cost in manufacturing of >> > low-cost and/or constrained device by not having to have IDevID >> >> I didn't get that all from the original poster. >> I think you are jumping to a conclusion that is not supported by text here. > > Yes, i was elaborating about why one would want an IDevID without the > serialNumber and what would need to happen to support that. But i also > said this should be out of scope for the current BRSKI document. > >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a SHOULD. >> And, that's not the point at all, really. >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN. > > Agreed. > >> 802.1AR-2009, has section 7.2.8: >> >> 7.2.8 subject >> The DevID subject field shall uniquely identify the device associated >> with the particular DevID credential within the issuer???s domain of >> significance. The formatting of this field shall contain a unique X.500 >> Distinguished Name (DN). This may include the unique device serial >> number assigned by the manufacturer or any other suitable unique DN >> value that the issuer prefers. In the case of a third-party CA or a >> standards certification agency, this can contain the manufacturer???s >> identity information. >> >> The subject field???s DN encoding should include >> the ???serialNumber??? attribute with the device???s unique serial number. >> >> Note lack of RFC2119 language (or a reference to it). >> >> So if the 2018 has "SHOULD" here, then that's a strengthing of the language, >> not a weaking. >> The first paragraph does have weasel words "any other >> suitable unique DN", but > > Ok, i currently can't access the IEEE standards, so i can not compare > myself. My reading of the OP was that it was a weakening. > > >> I really think that a serialNumber DN attribute >> (as opposed to the serialNumber certificate attribute) is needed for BRSKI >> to interoperate well. > > Agreed. > >> If someone has a 10 million devices in the field which can be field upgraded >> to run BRSKI (while still in a not-yet enrolled state in a box), then let's >> talk about this. Maybe it's actually 10,000,000 TPM devices with IDevIDs >> already generated, but no serialNumber in it. Getting the JRC code right >> to do other things can be a pain, but it can be done. > > Right, this was my question to the OP as well. I was guessing its more > about minimizing cost for future built 10 million devices. Today you > would need to burn-in during manufacturing identity elements such as > specifically the serialNumber, so you need to devise a protected burn-in > process. If you just et the device generate a public key pair and you > simply capture the public key during manufacturing, maybe that is a > significant simplification when you talk 10 million devices. Just > guessing. In any case, serialNumber is a lot more useful when humans are > involved, but they may become less relevant when everything is > automated. > > Cheers > Toerless > >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | IoT architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> > > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > From nobody Wed Jul 31 04:12:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5510C120114 for ; Wed, 31 Jul 2019 04:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6YRbz6gmoTBP for ; Wed, 31 Jul 2019 04:12:02 -0700 (PDT) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859641200F6 for ; Wed, 31 Jul 2019 04:12:02 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 04:12:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,330,1559545200"; d="scan'208";a="256111785" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 31 Jul 2019 04:12:00 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 31 Jul 2019 04:12:00 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 31 Jul 2019 04:11:59 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 31 Jul 2019 04:11:59 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.134]) by LCSMSX153.ger.corp.intel.com ([169.254.8.138]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 14:11:55 +0300 From: "Mendelson, Tsippy" To: Brian E Carpenter , Toerless Eckert , Michael Richardson CC: "Jayanna, Prabhu" , "anima@ietf.org" , "Ruan, Xiaoyu" , "Smith, Ned" , "Bhargav-Spantzel, Abhilasha" Thread-Topic: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 Thread-Index: AdUvGpUo2g/H2b+cQWiZ9uaJTHYs9ASHR2sAAXKBXoAAAqQ3gAABrQEAAAaDvQAAGBeysA== Date: Wed, 31 Jul 2019 11:11:54 +0000 Message-ID: <27D27ED4408AA64998F40FB212076767DC286696@hasmsx109.ger.corp.intel.com> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> <31027.1564525417@localhost> <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> In-Reply-To: <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2FjYTA0NzEtZGMwMi00MGVkLTlhZTYtZDZjYzI4Yzg5YTVkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYXVwMUloZGlhSE16U0JJY281ZzVWRDBQVkJoUUZSZWQ5aFVzTkxhUmkrUm5tR1QxN1RLOXd2STdYbGpMRWU2bSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 11:12:05 -0000 SGksDQoNCk15IHJlbWFyayB3YXMgYWJvdXQgdGhlIGluYWNjdXJhdGUgcmVmZXJlbmNlIHRvIElF RUUgODAyLjFBUiByZXF1aXJpbmcgU2VyaWFsIE51bWJlciBhcyBhIE1VU1QgaW4gdGhlIElEZXZJ RCAtIHRoaXMgY2FuIGJlIGVhc2lseSBmaXhlZCBieSBzYXlpbmcgdGhhdCBJRUVFIDgwMi4xQVIg cmVjb21tZW5kcyB0aGlzIGJ1dCBCUlNLSSBlbmZvcmNlcyB0aGlzIC0gbWFrZXMgdGhpcyBhIE1V U1QuDQoNCkJ1dCBiZWhpbmQgdGhlIHNjZW5lcyB0aGlzIHF1ZXN0aW9uIHdhcyBjb21pbmcgZnJv bSBjb25zaWRlcmF0aW9ucyByZWxhdGVkIHRvIGNvbXBsZXhpdHkgdGhhdCB0aGlzIGFkZHMgdG8g dGhlIG1hbnVmYWN0dXJpbmcgZmxvdyB3aGVuIHJlcXVpcmVkIHRvIHByb3Zpc2lvbiBldmVyeSBk ZXZpY2Ugd2l0aCBhIGNlcnRpZmljYXRlIHRoYXQgaW5jbHVkZXMgaXRzIFNlcmlhbCBOdW1iZXIg Oi0pLg0KVGhpcyBjcmVhdGVzIHVzYWJpbGl0eSBhbmQgc2VjdXJpdHkgaXNzdWVzIG9uIHRoZSBt YW51ZmFjdHVyaW5nIGxpbmUuDQoNCldlIGFyZSBkZXZpc2luZyBhIHNvbHV0aW9uIGZvciB0aGlz IG1hbnVmYWN0dXJpbmcgcHJvYmxlbSBieSB1c2luZyBhbiBlbWJlZGRlZCBDQSBpbiBhIFJvVCAv IEhhcmR3YXJlIFRFRSBpbiB0aGUgcGxhdGZvcm0gZm9yIHRoaXMgcHVycG9zZSAtIGJ1dCB0aGVy ZSBhcmUgY29uY2VybnMgd2l0aCB0aGlzIGltcGxlbWVudGF0aW9uIGFzIHdlbGwuIFRoZXJlZm9y ZSBJIHdhbnRlZCB0byBjbGFyaWZ5IHRoaXMgcmVxdWlyZW1lbnQuIChBbHRob3VnaCBJIGFncmVl IHRoYXQgaXQgbWFrZXMgcGVyZmVjdCBzZW5zZSkuDQoNClJlZ2FyZGluZzogDQoiIElmIHlvdSBq dXN0IGxldCB0aGUgZGV2aWNlIGdlbmVyYXRlIGEgcHVibGljIGtleSBwYWlyIGFuZCB5b3Ugc2lt cGx5IGNhcHR1cmUgdGhlIHB1YmxpYyBrZXkgZHVyaW5nIG1hbnVmYWN0dXJpbmcsIG1heWJlIHRo YXQgaXMgYSBzaWduaWZpY2FudCBzaW1wbGlmaWNhdGlvbiB3aGVuIHlvdSB0YWxrIDEwIG1pbGxp b24gZGV2aWNlcyINCg0KVGhpcyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgcmVtYXJrIGFzIHdlIGFy ZSBhY3R1YWxseSB0aGlua2luZyBvZiBhIHNvbHV0aW9uIHdoZXJlIHRoZSBQbGF0Zm9ybSBJZGVu dGlmaWVyIGluIHRoZSBPd25lcnNoaXAgVm91Y2hlciAodGhhdCB0aGUgT0VNIHVwbG9hZHMgdG8g dGhlaXIgaW52ZW50b3J5IGZyb20gdGhlIG1hbnVmYWN0dXJpbmcgbGluZSkgd291bGQgaW5jbHVk ZSAyIGNvbXBvbmVudHM6DQoxLiBUaGUgU2VyaWFsIE51bWJlciBhc3NpZ25lZCBieSB0aGUgT0VN IHRvIHRoZSBwbGF0Zm9ybSAtIHRoaXMgY291bGQgYmUgYSBTZXJ2aWNlIFRhZyBvciBwZXJoYXBz IGEgaGFzaCBvZiBhbGwgc2VyaWFsIG51bWJlcnMgb2YgZGV2aWNlcyBpbmNsdWRlZCBpbiB0aGUg cGxhdGZvcm0gLSBvciBzb21ldGhpbmcgZWxzZSB0aGUgT0VNIGNob29zZXMgLSBidXQgYXMgaXQg Y2FuIGJlIGEgaGFzaCB3ZSBhbGxvY2F0ZSAzMiBieXRlcyBmb3IgaXQuDQoNCjIuIEEgaGFzaCBv ZiB0aGUgUHVibGljIEtleSBvZiBhIGtleSBwYWlyIHRoYXQgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBQ bGF0Zm9ybSBSb1QgZm9yIGlkZW50aXR5IC8gVEVFIC0gdGhpcyB3b3VsZCBiZSB0aGUgcHVibGlj IGtleSBpbiB0aGUgSURldklEIGNlcnRpZmljYXRlLiBXaGVuIHVzaW5nIGFuIGVtYmVkZGVkIENB IChpbiB0aGUgUm9UIGhhcmR3YXJlKSB0byBpc3N1ZSBJRGV2SUQgY2VydGlmaWNhdGVzLCB0aGlz IHdvdWxkIGJlIHRoZSBQdWJsaWMgS2V5IGluIHRoZSBjZXJ0aWZpY2F0ZSBvZiB0aGUgZW1iZWRk ZWQgQ0EgdGhhdCB0aGUgSURldklEIENlcnRpZmljYXRlIGlzIHJvb3RlZCB0by4NCg0KQWx0b2dl dGhlciA2NCBieXRlcy4NCg0KVXNpbmcgYW4gZW1iZWRkZWQgQ0EgZW5hYmxlcyByZXZva2luZyBh bmQgcmVwbGFjaW5nIHRoZSBrZXkgYW5kIGNlcnRpZmljYXRlIHVzZWQgZm9yIGlkZW50aXR5IGF0 dGVzdGF0aW9uIGVhc2lseSwgYWZ0ZXIgYSBGVyB1cGRhdGUgdGhhdCBpbmNyZWFzZXMgdGhlIHNl Y3VyaXR5IHZlcnNpb24gbnVtYmVyLiANCg0KUmVnYXJkcywNClRzaXBweQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDMxLCAyMDE5IDA1 OjE4DQpUbzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPjsgTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQpDYzogSmF5YW5uYSwgUHJhYmh1IDxwcmFiaHUu amF5YW5uYUBpbnRlbC5jb20+OyBNZW5kZWxzb24sIFRzaXBweSA8dHNpcHB5Lm1lbmRlbHNvbkBp bnRlbC5jb20+OyBhbmltYUBpZXRmLm9yZzsgUnVhbiwgWGlhb3l1IDx4aWFveXUucnVhbkBpbnRl bC5jb20+DQpTdWJqZWN0OiBSZTogW0FuaW1hXSBDbGFyaWZpY2F0aW9uIHJlZyBvbGQgcmVmZXJl bmNlIGluIHRoZSBCUlNLSSBkcmFmdCB0byBJRUVFIDgwMl8xQVItMjAwOQ0KDQpMZXQncyBiZSBj bGVhciBpbiB0aGUgQlJTS0kgdGV4dCB0aGF0IG91ciBzdGFuZGFyZCBtYWtlcyB0aGlzIGEgTVVT VCAqZXZlbiBpZiogaXQgaXMgbm90IG1hbmRhdG9yeSBpbiB0aGUgSUVFRSBzdGFuZGFyZC4gT2Yg Y291cnNlIHdlIGNhbiBkbyB0aGF0IChhbmQgbm90IGluY2x1ZGluZyB0aGUgc2VyaWFsIG51bWJl ciBzZWVtcyB2ZXJ5IHNsb3BweSksIGJ1dCB3ZSBzaG91bGQgYmUgZXhwbGljaXQgdGhhdCBvdXIg cmVxdWlyZW1lbnQgaXMgc3Ryb25nZXIgdGhhbiB0aGUgSUVFRS4NCg0KTWF5YmUgaXQgbWVhbnMg dGhhdCBzb21lIGxpZ2h0IGJ1bGJzIGNhbm5vdCBiZSBCUlNLSSBwbGVkZ2VzLiBJIGRvbid0IHRo aW5rIHdlIGNhcmUsIGJlY2F1c2Ugb3VyIG1vZGVsIGlzIHRoYXQgbm9kZXMgY29udGFpbmluZyBt YW5hZ2VtZW50IHNtYXJ0cyBzdWNoIGFzIGFuIEFTQSBuZWVkIHRvIGpvaW4gdGhlIEFDUCwgYnV0 IG1hbmFnZWQgbm9kZXMgdGhlbXNlbHZlcyBkbyBub3QuDQoNClJlZ2FyZHMNCiAgIEJyaWFuDQoN Ck9uIDMxLUp1bC0xOSAxMToxMSwgVG9lcmxlc3MgRWNrZXJ0IHdyb3RlOg0KPiBPbiBUdWUsIEp1 bCAzMCwgMjAxOSBhdCAwNjoyMzozN1BNIC0wNDAwLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6 DQo+Pg0KPj4gVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPiB3cm90ZToNCj4+ICAgICA+ IEZyb20gd2hhdCBpIHVuZGVyc3RhbmQgKGFuZCBwbGVhc2UgY29ycmVjdCBtZSBpZiB5b3UgYXJl IGNvbWluZyBmcm9tIGENCj4+ICAgICA+IGRpZmZlcmVudCBhbmdsZSksIHlvdSBtYXkgYmUgYWJs ZSB0byByZWR1Y2UgY29zdCBpbiBtYW51ZmFjdHVyaW5nIG9mDQo+PiAgICAgPiBsb3ctY29zdCBh bmQvb3IgY29uc3RyYWluZWQgZGV2aWNlIGJ5IG5vdCBoYXZpbmcgdG8gaGF2ZSBJRGV2SUQNCj4+ DQo+PiBJIGRpZG4ndCBnZXQgdGhhdCBhbGwgZnJvbSB0aGUgb3JpZ2luYWwgcG9zdGVyLg0KPj4g SSB0aGluayB5b3UgYXJlIGp1bXBpbmcgdG8gYSBjb25jbHVzaW9uIHRoYXQgaXMgbm90IHN1cHBv cnRlZCBieSB0ZXh0IGhlcmUuDQo+IA0KPiBZZXMsIGkgd2FzIGVsYWJvcmF0aW5nIGFib3V0IHdo eSBvbmUgd291bGQgd2FudCBhbiBJRGV2SUQgd2l0aG91dCB0aGUgDQo+IHNlcmlhbE51bWJlciBh bmQgd2hhdCB3b3VsZCBuZWVkIHRvIGhhcHBlbiB0byBzdXBwb3J0IHRoYXQuIEJ1dCBpIGFsc28g DQo+IHNhaWQgdGhpcyBzaG91bGQgYmUgb3V0IG9mIHNjb3BlIGZvciB0aGUgY3VycmVudCBCUlNL SSBkb2N1bWVudC4NCj4gDQo+PiBUaGV5IHNpbXBseSBzYXkgdGhhdCBzZXJpYWxOdW1iZXIgaXMg bm90IGEgTVVTVCBpbiA4MDIuMUFSLTIwMTgsIGJ1dCByYXRoZXIgYSBTSE9VTEQuDQo+PiBBbmQs IHRoYXQncyBub3QgdGhlIHBvaW50IGF0IGFsbCwgcmVhbGx5Lg0KPj4gSUYgeW91IHdhbnQgdG8g ZG8gQlJTS0ksIHRoZW4geW91IE1VU1QgaW5jbHVkZSBhIHNlcmlhbE51bWJlciBpbiB0aGUgRE4u DQo+IA0KPiBBZ3JlZWQuDQo+IA0KPj4gODAyLjFBUi0yMDA5LCBoYXMgc2VjdGlvbiA3LjIuODoN Cj4+DQo+PiA3LjIuOCBzdWJqZWN0DQo+PiAgICAgICBUaGUgRGV2SUQgc3ViamVjdCBmaWVsZCBz aGFsbCB1bmlxdWVseSBpZGVudGlmeSB0aGUgZGV2aWNlIGFzc29jaWF0ZWQNCj4+ICAgICAgIHdp dGggdGhlIHBhcnRpY3VsYXIgRGV2SUQgY3JlZGVudGlhbCB3aXRoaW4gdGhlIGlzc3Vlcj8/P3Mg ZG9tYWluIG9mDQo+PiAgICAgICBzaWduaWZpY2FuY2UuIFRoZSBmb3JtYXR0aW5nIG9mIHRoaXMg ZmllbGQgc2hhbGwgY29udGFpbiBhIHVuaXF1ZSBYLjUwMA0KPj4gICAgICAgRGlzdGluZ3Vpc2hl ZCBOYW1lIChETikuIFRoaXMgbWF5IGluY2x1ZGUgdGhlIHVuaXF1ZSBkZXZpY2Ugc2VyaWFsDQo+ PiAgICAgICBudW1iZXIgYXNzaWduZWQgYnkgdGhlIG1hbnVmYWN0dXJlciBvciBhbnkgb3RoZXIg c3VpdGFibGUgdW5pcXVlIERODQo+PiAgICAgICB2YWx1ZSB0aGF0IHRoZSBpc3N1ZXIgcHJlZmVy cy4gSW4gdGhlIGNhc2Ugb2YgYSB0aGlyZC1wYXJ0eSBDQSBvciBhDQo+PiAgICAgICBzdGFuZGFy ZHMgY2VydGlmaWNhdGlvbiBhZ2VuY3ksIHRoaXMgY2FuIGNvbnRhaW4gdGhlIG1hbnVmYWN0dXJl cj8/P3MNCj4+ICAgICAgIGlkZW50aXR5IGluZm9ybWF0aW9uLg0KPj4NCj4+ICAgICAgIFRoZSBz dWJqZWN0IGZpZWxkPz8/cyBETiBlbmNvZGluZyBzaG91bGQgaW5jbHVkZQ0KPj4gICAgICAgdGhl ID8/P3NlcmlhbE51bWJlcj8/PyBhdHRyaWJ1dGUgd2l0aCB0aGUgZGV2aWNlPz8/cyB1bmlxdWUg c2VyaWFsIG51bWJlci4NCj4+DQo+PiBOb3RlIGxhY2sgb2YgUkZDMjExOSBsYW5ndWFnZSAob3Ig YSByZWZlcmVuY2UgdG8gaXQpLg0KPj4NCj4+IFNvIGlmIHRoZSAyMDE4IGhhcyAiU0hPVUxEIiBo ZXJlLCB0aGVuIHRoYXQncyBhIHN0cmVuZ3RoaW5nIG9mIHRoZSANCj4+IGxhbmd1YWdlLCBub3Qg YSB3ZWFraW5nLg0KPj4gVGhlIGZpcnN0IHBhcmFncmFwaCBkb2VzIGhhdmUgd2Vhc2VsIHdvcmRz ICJhbnkgb3RoZXIgc3VpdGFibGUgdW5pcXVlIA0KPj4gRE4iLCBidXQNCj4gDQo+IE9rLCBpIGN1 cnJlbnRseSBjYW4ndCBhY2Nlc3MgdGhlIElFRUUgc3RhbmRhcmRzLCBzbyBpIGNhbiBub3QgY29t cGFyZSANCj4gbXlzZWxmLiBNeSByZWFkaW5nIG9mIHRoZSBPUCB3YXMgdGhhdCBpdCB3YXMgYSB3 ZWFrZW5pbmcuDQo+IA0KPiANCj4+IEkgcmVhbGx5IHRoaW5rIHRoYXQgYSBzZXJpYWxOdW1iZXIg RE4gYXR0cmlidXRlIChhcyBvcHBvc2VkIHRvIHRoZSANCj4+IHNlcmlhbE51bWJlciBjZXJ0aWZp Y2F0ZSBhdHRyaWJ1dGUpIGlzIG5lZWRlZCBmb3IgQlJTS0kgdG8gDQo+PiBpbnRlcm9wZXJhdGUg d2VsbC4NCj4gDQo+IEFncmVlZC4NCj4gDQo+PiBJZiBzb21lb25lIGhhcyBhIDEwIG1pbGxpb24g ZGV2aWNlcyBpbiB0aGUgZmllbGQgd2hpY2ggY2FuIGJlIGZpZWxkIA0KPj4gdXBncmFkZWQgdG8g cnVuIEJSU0tJICh3aGlsZSBzdGlsbCBpbiBhIG5vdC15ZXQgZW5yb2xsZWQgc3RhdGUgaW4gYSAN Cj4+IGJveCksIHRoZW4gbGV0J3MgdGFsayBhYm91dCB0aGlzLiAgTWF5YmUgaXQncyBhY3R1YWxs eSAxMCwwMDAsMDAwIFRQTSANCj4+IGRldmljZXMgd2l0aCBJRGV2SURzIGFscmVhZHkgZ2VuZXJh dGVkLCBidXQgbm8gc2VyaWFsTnVtYmVyIGluIGl0LiAgDQo+PiBHZXR0aW5nIHRoZSBKUkMgY29k ZSByaWdodCB0byBkbyBvdGhlciB0aGluZ3MgY2FuIGJlIGEgcGFpbiwgYnV0IGl0IGNhbiBiZSBk b25lLg0KPiANCj4gUmlnaHQsIHRoaXMgd2FzIG15IHF1ZXN0aW9uIHRvIHRoZSBPUCBhcyB3ZWxs LiBJIHdhcyBndWVzc2luZyBpdHMgbW9yZSANCj4gYWJvdXQgbWluaW1pemluZyBjb3N0IGZvciBm dXR1cmUgYnVpbHQgMTAgbWlsbGlvbiBkZXZpY2VzLiBUb2RheSB5b3UgDQo+IHdvdWxkIG5lZWQg dG8gYnVybi1pbiBkdXJpbmcgbWFudWZhY3R1cmluZyBpZGVudGl0eSBlbGVtZW50cyBzdWNoIGFz IA0KPiBzcGVjaWZpY2FsbHkgdGhlIHNlcmlhbE51bWJlciwgc28geW91IG5lZWQgdG8gZGV2aXNl IGEgcHJvdGVjdGVkIA0KPiBidXJuLWluIHByb2Nlc3MuIElmIHlvdSBqdXN0IGV0IHRoZSBkZXZp Y2UgZ2VuZXJhdGUgYSBwdWJsaWMga2V5IHBhaXIgDQo+IGFuZCB5b3Ugc2ltcGx5IGNhcHR1cmUg dGhlIHB1YmxpYyBrZXkgZHVyaW5nIG1hbnVmYWN0dXJpbmcsIG1heWJlIHRoYXQgDQo+IGlzIGEg c2lnbmlmaWNhbnQgc2ltcGxpZmljYXRpb24gd2hlbiB5b3UgdGFsayAxMCBtaWxsaW9uIGRldmlj ZXMuIEp1c3QgDQo+IGd1ZXNzaW5nLiBJbiBhbnkgY2FzZSwgc2VyaWFsTnVtYmVyIGlzIGEgbG90 IG1vcmUgdXNlZnVsIHdoZW4gaHVtYW5zIA0KPiBhcmUgaW52b2x2ZWQsIGJ1dCB0aGV5IG1heSBi ZWNvbWUgbGVzcyByZWxldmFudCB3aGVuIGV2ZXJ5dGhpbmcgaXMgDQo+IGF1dG9tYXRlZC4NCj4g DQo+IENoZWVycw0KPiAgICAgVG9lcmxlc3MNCj4gDQo+PiAtLSANCj4+IF0gICAgICAgICAgICAg ICBOZXZlciB0ZWxsIG1lIHRoZSBvZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0 d29ya3MgWw0KPj4gXSAgIE1pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdv cmtzICAgICAgICB8ICAgIElvVCBhcmNoaXRlY3QgICBbDQo+PiBdICAgICBtY3JAc2FuZGVsbWFu LmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAgIHwgICBydWJ5IG9uIHJhaWxzICAg IFsNCj4+DQo+IA0KPiANCj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+PiBBbmltYUBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiANCj4gDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KSW50ZWwgSXNyYWVsICg3NCkgTGltaXRlZAoKVGhpcyBlLW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3Ry aWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIGFsbCBjb3BpZXMuCg== From nobody Wed Jul 31 10:59:39 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D42120618 for ; Wed, 31 Jul 2019 10:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AlA-Sm5BoWyl for ; Wed, 31 Jul 2019 10:59:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448F712060E for ; Wed, 31 Jul 2019 10:59:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 08E8B54805E; Wed, 31 Jul 2019 19:59:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EDBDD440041; Wed, 31 Jul 2019 19:59:28 +0200 (CEST) Date: Wed, 31 Jul 2019 19:59:28 +0200 From: Toerless Eckert To: "Mendelson, Tsippy" Cc: Brian E Carpenter , Michael Richardson , "Jayanna, Prabhu" , "anima@ietf.org" , "Ruan, Xiaoyu" , "Smith, Ned" , "Bhargav-Spantzel, Abhilasha" Message-ID: <20190731175928.2bipg4tlfoykyma6@faui48f.informatik.uni-erlangen.de> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> <31027.1564525417@localhost> <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> <27D27ED4408AA64998F40FB212076767DC286696@hasmsx109.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27D27ED4408AA64998F40FB212076767DC286696@hasmsx109.ger.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 17:59:38 -0000 On Wed, Jul 31, 2019 at 11:11:54AM +0000, Mendelson, Tsippy wrote: > Hi, > > My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 802.1AR recommends this but BRSKI enforces this - makes this a MUST. Ack. > But behind the scenes this question was coming from considerations related to complexity that this adds to the manufacturing flow when required to provision every device with a certificate that includes its Serial Number :-). > This creates usability and security issues on the manufacturing line. Thanks. Thats what i was guessing im my reply. > We are devising a solution for this manufacturing problem by using an embedded CA in a RoT / Hardware TEE in the platform for this purpose - but there are concerns with this implementation as well. Therefore I wanted to clarify this requirement. (Although I agree that it makes perfect sense). > > Regarding: > " If you just let the device generate a public key pair and you simply capture the public key during manufacturing, maybe that is a significant simplification when you talk 10 million devices" > > This is a very interesting remark as we are actually thinking of a solution where the Platform Identifier in the Ownership Voucher (that the OEM uploads to their inventory from the manufacturing line) would include 2 components: > 1. The Serial Number assigned by the OEM to the platform - this could be a Service Tag or perhaps a hash of all serial numbers of devices included in the platform - or something else the OEM chooses - but as it can be a hash we allocate 32 bytes for it. I can not quite imagine what you are calling a "platform". Could give give one or two examples ? > 2. A hash of the Public Key of a key pair that is generated by the Platform RoT for identity / TEE - this would be the public key in the IDevID certificate. When using an embedded CA (in the RoT hardware) to issue IDevID certificates, this would be the Public Key in the certificate of the embedded CA that the IDevID Certificate is rooted to. RoT ? TEE ? > Altogether 64 bytes. > > Using an embedded CA enables revoking and replacing the key and certificate used for identity attestation easily, after a FW update that increases the security version number. See above, i can't quite imagine the solution and its intended workflows, but it sounds as if oyu wanted to figure out a variation of BRSKI/MASA to actually enroll IDevID instead of LDevID... It seems the main problem you want to solve is how client devices should identify themselves to the MASA (or however else you want to call the manufacturer or OEM backend) without a classical certificate IDevID and without upfront tracking of any other form of serial IDs by the manufacturer ? I am not sure about all useful crypto mechanisms to solve this, but obviously you could have something like a platform-id in a TPM chip thats the same for all devices for the platform, and the only operation permitted is some proof of knowledge of that shared secret by the MASA (e.g.: hash(nonce+secret) or the like). Of course if you can born something unique into the devices during manufacturing, you could do something like very_long_serial=random(seed), seed becomes the platform identifier, and device identifies by sending masa-private-key encrypted serial to MASA. Or something like that. Crypto folks would likely have better suggestions ;-) Cheers Toerless > Regards, > Tsippy > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Wednesday, July 31, 2019 05:18 > To: Toerless Eckert ; Michael Richardson > Cc: Jayanna, Prabhu ; Mendelson, Tsippy ; anima@ietf.org; Ruan, Xiaoyu > Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 > > Let's be clear in the BRSKI text that our standard makes this a MUST *even if* it is not mandatory in the IEEE standard. Of course we can do that (and not including the serial number seems very sloppy), but we should be explicit that our requirement is stronger than the IEEE. > > Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think we care, because our model is that nodes containing management smarts such as an ASA need to join the ACP, but managed nodes themselves do not. > > Regards > Brian > > On 31-Jul-19 11:11, Toerless Eckert wrote: > > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: > >> > >> Toerless Eckert wrote: > >> > From what i understand (and please correct me if you are coming from a > >> > different angle), you may be able to reduce cost in manufacturing of > >> > low-cost and/or constrained device by not having to have IDevID > >> > >> I didn't get that all from the original poster. > >> I think you are jumping to a conclusion that is not supported by text here. > > > > Yes, i was elaborating about why one would want an IDevID without the > > serialNumber and what would need to happen to support that. But i also > > said this should be out of scope for the current BRSKI document. > > > >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a SHOULD. > >> And, that's not the point at all, really. > >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN. > > > > Agreed. > > > >> 802.1AR-2009, has section 7.2.8: > >> > >> 7.2.8 subject > >> The DevID subject field shall uniquely identify the device associated > >> with the particular DevID credential within the issuer???s domain of > >> significance. The formatting of this field shall contain a unique X.500 > >> Distinguished Name (DN). This may include the unique device serial > >> number assigned by the manufacturer or any other suitable unique DN > >> value that the issuer prefers. In the case of a third-party CA or a > >> standards certification agency, this can contain the manufacturer???s > >> identity information. > >> > >> The subject field???s DN encoding should include > >> the ???serialNumber??? attribute with the device???s unique serial number. > >> > >> Note lack of RFC2119 language (or a reference to it). > >> > >> So if the 2018 has "SHOULD" here, then that's a strengthing of the > >> language, not a weaking. > >> The first paragraph does have weasel words "any other suitable unique > >> DN", but > > > > Ok, i currently can't access the IEEE standards, so i can not compare > > myself. My reading of the OP was that it was a weakening. > > > > > >> I really think that a serialNumber DN attribute (as opposed to the > >> serialNumber certificate attribute) is needed for BRSKI to > >> interoperate well. > > > > Agreed. > > > >> If someone has a 10 million devices in the field which can be field > >> upgraded to run BRSKI (while still in a not-yet enrolled state in a > >> box), then let's talk about this. Maybe it's actually 10,000,000 TPM > >> devices with IDevIDs already generated, but no serialNumber in it. > >> Getting the JRC code right to do other things can be a pain, but it can be done. > > > > Right, this was my question to the OP as well. I was guessing its more > > about minimizing cost for future built 10 million devices. Today you > > would need to burn-in during manufacturing identity elements such as > > specifically the serialNumber, so you need to devise a protected > > burn-in process. If you just et the device generate a public key pair > > and you simply capture the public key during manufacturing, maybe that > > is a significant simplification when you talk 10 million devices. Just > > guessing. In any case, serialNumber is a lot more useful when humans > > are involved, but they may become less relevant when everything is > > automated. > > > > Cheers > > Toerless > > > >> -- > >> ] Never tell me the odds! | ipv6 mesh networks [ > >> ] Michael Richardson, Sandelman Software Works | IoT architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >> > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. From nobody Wed Jul 31 11:02:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25582120684 for ; Wed, 31 Jul 2019 11:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 h98_htQq41GS for ; Wed, 31 Jul 2019 11:02:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650DB120699 for ; Wed, 31 Jul 2019 11:02:29 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A336554802C; Wed, 31 Jul 2019 20:02:24 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 94493440041; Wed, 31 Jul 2019 20:02:24 +0200 (CEST) Date: Wed, 31 Jul 2019 20:02:24 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , "Jayanna, Prabhu" , "Mendelson, Tsippy" , "anima@ietf.org" , "Ruan, Xiaoyu" Message-ID: <20190731180224.ndxekt7hvuize2p5@faui48f.informatik.uni-erlangen.de> References: <27D27ED4408AA64998F40FB212076767DC26B25F@hasmsx109.ger.corp.intel.com> <27D27ED4408AA64998F40FB212076767DC282548@hasmsx109.ger.corp.intel.com> <20190730210759.yaubbw2pit73a6sh@faui48f.informatik.uni-erlangen.de> <31027.1564525417@localhost> <20190730231136.x6oehxkjokspgcxn@faui48f.informatik.uni-erlangen.de> <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fb6a7b6-4684-6b77-5ab5-db0387554e49@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 18:02:40 -0000 On Wed, Jul 31, 2019 at 02:18:08PM +1200, Brian E Carpenter wrote: > Let's be clear in the BRSKI text that our standard makes this a MUST > *even if* it is not mandatory in the IEEE standard. Of course we can do > that (and not including the serial number seems very sloppy), but we > should be explicit that our requirement is stronger than the IEEE. Right. > Maybe it means that some light bulbs cannot be BRSKI pledges. I don't > think we care, because our model is that nodes containing management > smarts such as an ASA need to join the ACP, but managed nodes themselves > do not. GRASP, BRSKI, ACP are meant to also be independently reuseable, not every device using eithrer of them needs the full ANI. My argument is rather that BRSKI as defined (mandating serialNumber) is well representing whats used/required in well known type of devices and that followon work can (IMHO) easily expand it for additional constrained device solutions. Cheers Toerless > Regards > Brian > > On 31-Jul-19 11:11, Toerless Eckert wrote: > > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote: > >> > >> Toerless Eckert wrote: > >> > From what i understand (and please correct me if you are coming from a > >> > different angle), you may be able to reduce cost in manufacturing of > >> > low-cost and/or constrained device by not having to have IDevID > >> > >> I didn't get that all from the original poster. > >> I think you are jumping to a conclusion that is not supported by text here. > > > > Yes, i was elaborating about why one would want an IDevID without the > > serialNumber and what would need to happen to support that. But i also > > said this should be out of scope for the current BRSKI document. > > > >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a SHOULD. > >> And, that's not the point at all, really. > >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN. > > > > Agreed. > > > >> 802.1AR-2009, has section 7.2.8: > >> > >> 7.2.8 subject > >> The DevID subject field shall uniquely identify the device associated > >> with the particular DevID credential within the issuer???s domain of > >> significance. The formatting of this field shall contain a unique X.500 > >> Distinguished Name (DN). This may include the unique device serial > >> number assigned by the manufacturer or any other suitable unique DN > >> value that the issuer prefers. In the case of a third-party CA or a > >> standards certification agency, this can contain the manufacturer???s > >> identity information. > >> > >> The subject field???s DN encoding should include > >> the ???serialNumber??? attribute with the device???s unique serial number. > >> > >> Note lack of RFC2119 language (or a reference to it). > >> > >> So if the 2018 has "SHOULD" here, then that's a strengthing of the language, > >> not a weaking. > >> The first paragraph does have weasel words "any other > >> suitable unique DN", but > > > > Ok, i currently can't access the IEEE standards, so i can not compare > > myself. My reading of the OP was that it was a weakening. > > > > > >> I really think that a serialNumber DN attribute > >> (as opposed to the serialNumber certificate attribute) is needed for BRSKI > >> to interoperate well. > > > > Agreed. > > > >> If someone has a 10 million devices in the field which can be field upgraded > >> to run BRSKI (while still in a not-yet enrolled state in a box), then let's > >> talk about this. Maybe it's actually 10,000,000 TPM devices with IDevIDs > >> already generated, but no serialNumber in it. Getting the JRC code right > >> to do other things can be a pain, but it can be done. > > > > Right, this was my question to the OP as well. I was guessing its more > > about minimizing cost for future built 10 million devices. Today you > > would need to burn-in during manufacturing identity elements such as > > specifically the serialNumber, so you need to devise a protected burn-in > > process. If you just et the device generate a public key pair and you > > simply capture the public key during manufacturing, maybe that is a > > significant simplification when you talk 10 million devices. Just > > guessing. In any case, serialNumber is a lot more useful when humans are > > involved, but they may become less relevant when everything is > > automated. > > > > Cheers > > Toerless > > > >> -- > >> ] Never tell me the odds! | ipv6 mesh networks [ > >> ] Michael Richardson, Sandelman Software Works | IoT architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >> > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > -- --- tte@cs.fau.de