[Netconf] issues with processing onboarding information (zerotouch)

Kent Watsen <kwatsen@juniper.net> Wed, 01 August 2018 02:36 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 64B33130F1F for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 19:36:24 -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=[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 (2048-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 aeV-xKa49zOa for <netconf@ietfa.amsl.com>; Tue, 31 Jul 2018 19:36:21 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 4E61C130E23 for <netconf@ietf.org>; Tue, 31 Jul 2018 19:36:21 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w712XvYG008065 for <netconf@ietf.org>; Tue, 31 Jul 2018 19:36:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=39e4ARvTJRwFJIkCaV4QpQvv35oul9Aptcq2hSGfBn0=; b=uDqFO+JMVxiusd4NTEHj5jDgMrGs28rXCJ30inOMvsE+i06RayEs49oSF6Xfe0pOrF6t 1ouRk21suJf0lBXZpWw13KJxObdOnRDcVe3lgib/7TXMy/fKgH+MWQzBN/s9VbXKyWwP BSRcBF0WaA3ga9y3+DJSg04R15drhhUO5+/V3FkUOw4CswsJKYJ1CVld6tySjSrboMyL XePgXrT0sd4adReHd6snaUIf/CDGKWtWNK8TN0G2Dd1pCZu5vRjO1RbTqtJ7f644V912 PAidYNvRZ//5eubCV1mRJ7F2AuCGzpuiIWS5RLkjXQqemayf/3QR46rpQsiHBsQs7Z+J gw==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0023.outbound.protection.outlook.com [216.32.181.23]) by mx0b-00273201.pphosted.com with ESMTP id 2kk3e5g1ts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <netconf@ietf.org>; Tue, 31 Jul 2018 19:36:20 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4651.namprd05.prod.outlook.com (20.176.109.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.14; Wed, 1 Aug 2018 02:36:17 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::e0bc:6a82:571d:258]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::e0bc:6a82:571d:258%2]) with mapi id 15.20.1017.010; Wed, 1 Aug 2018 02:36:17 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: issues with processing onboarding information (zerotouch)
Thread-Index: AQHUKUBsRXyoCV/rkEqjLY+tWFC5zw==
Date: Wed, 1 Aug 2018 02:36:17 +0000
Message-ID: <4C41A9DD-DEF1-4774-8BC9-E361A623AF5B@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
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4651; 6:jLyrXRcjaKt6IWyhcJyLidWkp3kdXIAAUKvvos/RJosbnEfNYDTyA/uBbhtaIu2l0FqnDTHObnZC3hyfbLL9aCiDMaz+6OdLuG15xbX4N66FfGRKOi16Q4OiOycLp5R7JTkBsqWlbC8K9JK88ui2jGW6XsAdY84Tyo082YE3jKZLMAywjwcM+spq4g6jCds9JGw1qGK9NqeiSwzFes+Ihq9YdUJdzgGHrWtC97sbgguZ+epd68TXnpAslGC62cYnBoTSzfP21a0VJ/JHOI3I4l+gKESwYBqLxr155n3wrO/FqlVXpDuxhP7JfLhRHZJblAHM/OtImTpJkPjFLCPIfEdOcX1E6AhjG3K3SN/2rQjRiRrdi3c2O1NCWC45iRel2D6nfeFmVdBpIMqVMeDgRTZW2QhLDFUDI2YgCZfBsY3z6yRBmGUHt0/26Q4oJtqNu2dxXfe2KPUkmq+WFc5SEw==; 5:6Mx/WZR/ENvvVDsLfQ3HiNXmlXsPU+Xon3vv6Gji4tIUeAI6jv4gnHbmTA0lko4MKmR4unpfC9gTQ6xk0am7b7gEaa1boaDuXsItYz8JVOdG/ZGEBCkaWqMxnTduuBBCC3opjhQXbVc8Gw7qH4j5xpO2MnqeqzYUXaVHGj1tjP4=; 7:flJL3/xFuGmSgKs7jjDCfuYG4z6cMQd74eysiubMqT+oxFQ81X1QN5KyPrh6q10pvcVTm1SMYxOryR2AdGP+FGGpORmja5pEPO6lBK9rThsYghX0Lxa/TwuXtj/KpMjaS7fxIh4dLvyYkTsXkCAAs4kLQ95CHFFuyH/o4y4Xox9McKlFw/1zyahfet48WcIANm3It7E2L1iVZzbRNEoCBOdzi7OsEsdYq4baokpGiQdgqUJfl8M9ZBet50mER/q3
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 26288e5b-f956-41d7-ed4e-08d5f7578eee
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4651;
x-ms-traffictypediagnostic: DM6PR05MB4651:
x-microsoft-antispam-prvs: <DM6PR05MB46516A88AF5A6F647FE63F0CA52D0@DM6PR05MB4651.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(211171220733660);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM6PR05MB4651; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4651;
x-forefront-prvs: 0751474A44
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(136003)(346002)(189003)(199004)(51444003)(97736004)(6916009)(6436002)(5640700003)(14454004)(82746002)(316002)(6512007)(83716003)(2906002)(25786009)(33656002)(66066001)(2900100001)(53936002)(68736007)(2351001)(5660300001)(6486002)(99286004)(1730700003)(8676002)(81166006)(478600001)(413944005)(81156014)(476003)(256004)(105586002)(305945005)(86362001)(186003)(36756003)(6506007)(58126008)(7736002)(26005)(106356001)(14444005)(102836004)(6116002)(5250100002)(8936002)(2501003)(486006)(2616005)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4651; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: z3E31ZNblpUYcPSsDp1BR3CH9s3+GSQLVA3PWU2BtDPOc3Nho1lTaJSaroY6GFmqBgOL6t0y/oXBBCVJYDfwYbmFnBrNgEyMN7zOToJ78NfIdOVb7lwxdNF7FhYAU8V967dFiNzW56urTvNRbdiWPydNomEo71YK2t4T5UOxDYGNKMaG+KUgvmXQ1GaDZUzHFAog7P/N+YqLpV5CoSuDady791aeNcWa9xRdA7h1M8pkHasCr5FI4fPTo4VImp3ebgPAqNoQ0XvKJ4vxXUGviKhXR4GCEEkZdxB6qJysQD1VmJwG21OMIB3AMVYm/xhNaNimSqcFZua/JD2Vl1JZm4nxEIgT5Yto7/UhdBkg0d0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <24B4F907573F6B4283E24710E35AB566@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 26288e5b-f956-41d7-ed4e-08d5f7578eee
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2018 02:36:17.3910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4651
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-01_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1808010026
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/5NZR-BhXGlVv-iSGrku0GX3p-Ec>
Subject: [Netconf] issues with processing onboarding information (zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 01 Aug 2018 02:36:24 -0000

Dear WG,

Three issues with the zerotouch draft were brought to my 
attention yesterday.  As author, I noticed that the draft
was still pending shepherd write up.  I discussed the matter
with the shepherd (Mahesh), who recommended sending this
email to the list regarding the issues, with the goal of
posting a -23 that the shepherd write up would use.

All issues regard Section 5.6 (Processing Onboarding 
Information).  

The following issues are presented in order of importance.


1) Strengthen text around state retained when an error is 
   encountered.  Currently the text is weak, to the point of
   concern.  There are a few places where change would be 
   needed as follows:

 a) Fix the high-level error handling statement:

    OLD
     If the device encounters an error at any step, it MUST
     NOT proceed to the next step.

    NEW
     If the device encounters an error at any step, it MUST
     stop processing the onboarding information and return to 
     the bootstrapping sequence described in Section 5.2.  It 
     is understood that some state may be retained from the
     bootstrapping process when the device returns to the
     bootstrapping sequence.  For instance, retained state
     may include the currently installed boot-image.  Any
     such retained state MUST NOT hinder the ability for
     the device to continue the bootstrapping sequence
     described in Section 5.2.

 b) Clarify that the scripts MUST also be idempotent, in case
    the bootstrapping process falls into a loop.  Alternatively,
    we could introduce a requirement on the scripts to supply
    some sort of clean-up command; then the only state retained
    would ever be the currently running boot-image, which is 
    fine.  Thoughts?

 c) change how script errors are handled from being "device
    reset" to "the script MUST not leave behind any state".
    This removes a potentially expensive reset, by shifting
    the onus to the script writers to do the right error
    handling logic.  Seems dangerous, but I think that it's
    fair to assume that the script can be written this way.

 d) remove the following text (it is dangerously misleading):

    If there is an error, and the device previously executed a
    pre-configuration script, the device does not need to reset
    itself in order to wipe out any state the script may have 
    left behind; this implies that the pre-configuration script
    must be idempotent.

 e) clarify that the configuration commit must be atomic.

 f) clarify that any error encountered after committing the
    configuration (e.g., in the "post-configuration-script")
    must rollback the configuration to the previous configuration.

 g) clarify that failure to successfully deliver the "bootstrap-
    complete" progress-type (i.e., the "report-progress" RPC
    returns HTTP 204) must be treated as an error.

 h) clarify that "return to bootstrapping sequence" is to be
    interpreted in the recursive context.  Meaning that the
    device rolls-back one loop, rather than start over from
    scratch.



2) Change the conformance for how the boot-image is verified.
   The text already says that the image MUST be verified, but
   then says:

     To verify the downloaded boot image, the device MUST
     check that the boot image file matches the verification
     fingerprint supplied by the onboarding information.

   Perhaps the MUST should be a MAY, as the image might
   alternatively have a built-in verification method (e.g.,
   an embedded signature)?

   We could further allow a fingerprint to NOT be supplied,
   stating that, for such devices, in case one is, the 
   device can send an "boot-image-warning" message.

   Finally, it's no longer just one fingerprint, but a list,
   so the above text is misleading.

   All put together, the above could be rewritten as:

     To verify the downloaded boot image, the device MAY
     check that the boot image file matches one of the
     verification fingerprints supplied by the onboarding
     information.  In case verification fingerprints are
     supplied, but the device doesn't use them, it SHOULD
     send a "boot-image-warning" progress report message.



3) add more zerotouch "progress-type" enums, and maybe
   make more of them mandatory?

  Module ietf-zerotouch-bootstrap-server contains the RPC
  report-progress, which has input leaf "progress-type", 
  which is an enumeration.  Currently, the enums follow
  this pattern:

   - bootstrap-initiated
   - bootstrap-complete
   - <step>-warning
   - <step>-error
   - informational

  where <step> has values: parsing, boot-image, pre-script,
  config, and post-script.

  a) Should we add additional well-typed values for visibility
     reasons (i.e. more debug information sent to the bootstrap
     server)?  Specifically, these two:

      - <step>-initiated
      - <step>-success

  b) assuming (a), should we make more of the reporting of
     progress mandatory?  Currently only "bootstrap-complete"
     is mandatory, with everything else being a SHOULD.



If no objections a raised, I'll plan to make these changes
next week.


Thanks,
Kent // author