[Netconf] send 'version' in zerotouch url?

Kent Watsen <kwatsen@juniper.net> Thu, 17 August 2017 14:52 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828EC1252BA for <netconf@ietfa.amsl.com>; Thu, 17 Aug 2017 07:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 CNRVZ-626QBD for <netconf@ietfa.amsl.com>; Thu, 17 Aug 2017 07:52:21 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CED413201E for <netconf@ietf.org>; Thu, 17 Aug 2017 07:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dmtSjF/CQvX6s4s16pqbbe13NzPuGb69SyF11k2JIv8=; b=SR/+wUz30rp8S6l1CQ9aWKrf5OKgDVUpBn72wsE0igdlFXoCOijX0pHfIXFq5f9pIB0DaBxDSAGUJmiqflF4OZ3lwctMG0PQFMZVB5cfa35KhzUUuWVe4+6xsY1gJ0Hb0r+bumJpZ2AmcFTNpw9lNNQ1aPTk0KoI+4maPZzpCdI=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1492.namprd05.prod.outlook.com (10.160.117.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Thu, 17 Aug 2017 14:52:19 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1385.003; Thu, 17 Aug 2017 14:52:19 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: send 'version' in zerotouch url?
Thread-Index: AQHTF2hsdmDyCZHvzEG1i1lcdCC7gw==
Date: Thu, 17 Aug 2017 14:52:19 +0000
Message-ID: <FCBE2DD3-F47A-4848-8BA7-D9E85F49D1AB@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1492; 6:PblRIsxx3XlpFlTmqazhQhvBN2885JK8wgLGXxkm08QrHPtxrZ4joS2fP/Z2HANICrSow2QBqgeooMcF1WjljJqNQJXFFKEN4SxsUW/cyXrGPqsTbsXjF0rWqSDJNggU2CzLoRScSRI0o7NnJL9zXh76BTd/k5bXhuKKXCgGlVUD+Ug7J4ri38eNNGwqwGoMe5+dSDJvy8BsLLUAk0jVgdGuRjE38ZYcCHL29XsGquhWD0pJkW9Od7rZzMjudZ0Bd+htivGsRa3eaPY6QpgZ9SK9DRMD9H+5v2yuGdklNCmdtUaiTXE/JFA6F0JOEe6sqQgOhAmjVPHrPXh8OZG+3g==; 5:mlK52F8RxLv8LsWwtjCuWsdYqHwsiFRT7TdYfDWKFL+1u80IejTf4HpZZN4O3GFaby2hJnZrnwaFHxCyY8XRxzPdKvvHu0p0Fx4eKBJ8Kj7OY0F2CdZatbxcBvhfu2kdu//5e//sLaIGVGi4fuw5FtlCcsSbUaTDuSadeRX2Okk=; 24:VUlZThrgFq/oKspXNuwEgFp7jEKIWjWHl0aREIAEd+k4MLAnY8NUxMf6wFyPEtEZqgf8xdHJEpJnf08mQou3Ea5/ogNtVj3d7e7xnb+aG8E=; 7:ZopGW99VrglGfTa2z3YJe9V+LyobG1qhHVyplHEKK86vyTeNK4NG/4Hiy+b95dJ88bHcwJ2MbG5gl0Z1Lx5Vt+SQf/9uMYw7PduNR2fPtR0WtKSh7kWqy3v9fLumaMXMcvN00OHv0HHP7gkAonJ8409Uu7i+8kItLqSss4E7kwks/gkCgAMUeLMcme1IEb3hRlHy5alZq1dExgez6/ONxizxIur1a+mpiPAzOR0hf28=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ea53f0ab-8fe2-4e25-71e7-08d4e57f8f27
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1492;
x-ms-traffictypediagnostic: BN3PR0501MB1492:
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863);
x-microsoft-antispam-prvs: <BN3PR0501MB14928A82323B741EB35FAB54A5830@BN3PR0501MB1492.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1492; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1492;
x-forefront-prvs: 0402872DA1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(40224003)(199003)(14454004)(36756003)(6116002)(102836003)(3846002)(25786009)(101416001)(2351001)(110136004)(6306002)(6512007)(5640700003)(6436002)(6506006)(77096006)(6486002)(53936002)(86362001)(966005)(5660300001)(305945005)(6916009)(7736002)(99286003)(189998001)(97736004)(81166006)(1730700003)(81156014)(8936002)(8676002)(83716003)(83506001)(54356999)(50986999)(2900100001)(82746002)(2501003)(33656002)(66066001)(105586002)(106356001)(478600001)(2906002)(68736007)(4001350100001)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1492; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <95228FA731356D49A738D4D3C5B99E35@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 14:52:19.0010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1492
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/J4sLUM4ehJ8qxBcWQ5U7ZGS9AG8>
Subject: [Netconf] send 'version' in zerotouch url?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Aug 2017 14:52:23 -0000


It has come to my attention that the zerotouch draft is missing the ability for a device to inform a bootstrap-server what version of software the device is currently running.  Doing so would allow the server to potentially return a response specialized for the version of software the device says it is running.

The proposed change is to add a query-parameter called 'version' that the device can put into its GET request.  For example:

  GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:device=<unique-id>?version=<version> HTTP/1.1

One question might be if its mandatory to implement on the device or on the server.  Another question is if it matters if the device trusts the server of not.  

Currently the draft prevents devices from sending their IDEVID certificates, and also from POST-ing progress updates, to untrusted servers.  We can discuss if this is important or not.  If it is, then we should also discuss having devices send a hash of their serial-numbers, not their raw serial-numbers, since serial-numbers are very identifying.  Otherwise, if it's not important, we should discuss maybe allowing the devices to their IDEVID certs to untrusted servers too.

BTW, the draft used to have 'unique-id' everywhere, to allow for the possibility for the hashing of the serial-number, a manufacturer decision.  In my last update, I tried to make the draft align more with the fact that the IDEVID certificate and also the Ownership Voucher (from anima draft) both have *serial-numbers* in them.  But it seems that I also touched the bootstrap server API, the leaf is still called "unique-id", but the value is stated elsewhere to be the device's serial number.  I should back that change out so again it's a manufacturer-decision for how to encode 'unique-id'.  Tying this into the previous paragraph, this question is if the draft should make hashing a MUST, for privacy reasons

Any thoughts on any of this?

Thanks,
Kent  // contributor