Re: [Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Kent Watsen <kwatsen@juniper.net> Mon, 10 December 2018 23:04 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 BEE0F1312F7; Mon, 10 Dec 2018 15:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.16
X-Spam-Level:
X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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=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 gzcKmc4yiPkI; Mon, 10 Dec 2018 15:04:02 -0800 (PST)
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 D05E91312F9; Mon, 10 Dec 2018 15:04:00 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBAMxEWp006161; Mon, 10 Dec 2018 15:03:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=qyLuN2Uenm2bKpHVvsFHLBYyTXd12W3xOiu8WhW+raI=; b=XAQr35R+cl+/AohHA7x1SR3AyVBbnYsDXXevvAAfxC8Tta9WFeA6UR8F9hJqXmp/fhw3 QMssSDwwkTNuNLwg0kqMvhlblOLpt5QI14HBNoiffmqMPjfMNzb0S5E1SQ8Vs0hmCRwT VPeojfhvy9VKrk6sccCTL/N69vu+3vbyYoF00I4zzURdVUlQFE3D5/xSGa87dPRlFd+u udKGD6p5pXdzDMn/zpZbdT99PL+HQlLLa8KN95mn8Ekn7WDiVFoRNVZOoQIRcp3sXIMD Np+tBqPOQiIcpUuPezXcwTTdBKpAa/DVhbKwIiLvBMbqfYfW0tCswa3IPe40vLy0nEaZ FA==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2058.outbound.protection.outlook.com [104.47.33.58]) by mx0b-00273201.pphosted.com with ESMTP id 2p9ukagmj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Dec 2018 15:03:57 -0800
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5371.namprd05.prod.outlook.com (20.176.120.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Mon, 10 Dec 2018 23:03:50 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c%2]) with mapi id 15.20.1425.016; Mon, 10 Dec 2018 23:03:50 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Thread-Index: AQHUjMdfcgz3uvchk06pPxfK6ViltaV4S9WA
Date: Mon, 10 Dec 2018 23:03:49 +0000
Message-ID: <C6DF1C92-1132-4E8E-A27F-70B79157C9E7@juniper.net>
References: <154403409772.31942.18387130156502248943.idtracker@ietfa.amsl.com>
In-Reply-To: <154403409772.31942.18387130156502248943.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5371; 6:gpFIqWCL/an47Vd9+sRA/q1TVvg0Z+Px59O7J5Tf8lITDeyeKGzn2RzeSs3hsmaXD1CuhcOruTW9hRSvsHM68ym+OXvj9LMPp182bdkP5Bhi28X9nVwTm8pNsmQ4UBdSvRTw1OVDH6bMMm7dHIQ7AYNS37hYR+sUTQZbUJnrmXZdBnkEpQGp6CFcA+1M7kgikPzJLv5/VFunZXO4IH8bmoTysTXbxn9s5fBW/YFehsrAwEV2RBiNBies7B3oi9Kb6H7yBnt3MSy0Tj2uEncMQI8O+WZi+xNSBrrBsKySIEWThXzgTz88uV/+sh/ILrKvfCpyEvW3mZ2zGOC6ZL2q2KuzYsFjnpDqlX1jjl87Dd+R2XPQqhoMMkG6azLNkHzbSpTZatzG2bEXwg0hkk3FwUo+ECizk4NppmfltpmrWMdsf5qYkn7mZ/xohn36Zsf/lkOdC5gD4VgfRJq1bWKZNQ==; 5:oBwKDOcM0q56a+4dPuJDIKfznbS2Irr4pvrrusHYW2U1WTzJaZf5fuazUByA3lVfx6FXdRGsy1KuEXk070bhCMbDfzqSH1qW5nGVFnnOI6fhgxYjpjKkZ8cZjhMt4nWhDThDSUwPYpyt+SavenwV7fmJPpHLgJe5aUp+7BGgo84=; 7:XPdofCyKl92AFY9MF8TDlhbY9KLIDgUZ5AzV2p5Z2s/zwGApSgNp4enSQx4w3Ae7KryRERnOK70YgHsa1NMSupSt4PEHuwN9IvrW3U3cBYhYGqZeRCqfFAsQCko0rxZjVJpwe8gSWVdscw4HV7UUUw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 35a9da67-baba-4f4b-cd27-08d65ef3bf64
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5371;
x-ms-traffictypediagnostic: DM6PR05MB5371:
x-microsoft-antispam-prvs: <DM6PR05MB537173F239E7DBD804B294DBA5A50@DM6PR05MB5371.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231472)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5371; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5371;
x-forefront-prvs: 08828D20BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(366004)(346002)(376002)(199004)(189003)(3846002)(6116002)(8936002)(33656002)(36756003)(446003)(86362001)(575784001)(8676002)(71190400001)(71200400001)(486006)(81156014)(81166006)(2616005)(11346002)(476003)(83716004)(99286004)(229853002)(66066001)(105586002)(102836004)(106356001)(26005)(186003)(76176011)(6506007)(82746002)(110136005)(54906003)(58126008)(316002)(5660300001)(6486002)(7736002)(2906002)(305945005)(6436002)(345774005)(6246003)(6306002)(6512007)(68736007)(966005)(14444005)(14454004)(256004)(53936002)(97736004)(478600001)(25786009)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5371; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: piyNhEa0+F/Lsicukzp1yu0ZWuXOfHOpFFL8V10MB9R/FT8bxVWdVWnX7ortGeiA5rqEumxBQT9s/3jul1eFWmbaAaaPbEIXFy4Ir2k1n3pgnkO2ULZ4FsJ05R+ri/FbZNvnDkJcZetB2D/hV41AUck/sQtJ61TdW0FJhiEWdw/yMH0wnoZMy+Q/zMxDsGKE93dDktNNATU3EMfNz5esnL3fZFtQdrvXIs3QBP9ZLUYZyjOARNaaV8gohqL8ioaRPnY4Vmzu6Pxsd18WnwnysGAgl1d0ZLcT6UpDCdQpTwlcKGAsQCBiw1znkwIvjpvo
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <EDA74B2DA5D3D4499BC1ADC51C7250AB@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 35a9da67-baba-4f4b-cd27-08d65ef3bf64
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 23:03:49.9461 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5371
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-10_08:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812100206
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BgQqONbckunohhaOSftVogwu80E>
Subject: Re: [Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 10 Dec 2018 23:04:06 -0000

Hi Alexey,

Thanks for your review!
See below for responses.


Kent // coauthor



> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for a well written document, it was a pleasure to read.
> I have a small list of issues that I would like to discuss before
> recommending approval of this document:
>
>
> In Section 5.3:
>
>   If the zero touch information artifact contains redirect information,
>   the device MUST, within limits of how many recursive loops the device
>   allows, process the redirect information as described in Section 5.5.
>   This is the recursion step, it will cause the device to reenter this
>   algorithm, but this time the data source will definitely be a
>   bootstrap server, as that is all redirect information is able to
>   redirect a device to.
>
> I think you need to specify a "max redirect" value in order to
> prevent intentional or unintentional misconfigurations. Without
> such limit it is trivial to introduce denial-of-service attack
> on naive device implementations.

There is a Security Consideration on this very point, where is says:

   Implementations SHOULD limit the maximum number of recursive
   redirects allowed; no more than a half dozen seems reasonable.

Here's direct link:
  https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-25#section-9.9

Is this now acceptable as is?  If not, would it be suffice to 
add a reference the Security Consideration?  If not, then, yes,
a max-redirect value could be defined, but it would have to be 
somewhat high (25?) so that the standard doesn't prematurely
limit some unforeseen use.  Please advise.



> 2)
> 10.3.  The SMI Security for S/MIME CMS Content Type Registry
>
>   IANA is kindly requested to add two entries in the "SMI Security for
>   S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with
>   values as follows:
>
>   Decimal  Description                             References
>   -------  --------------------------------------  ----------
>   TBD1      id-ct-zerotouchInformationXML          [RFCXXXX]
>   TBD2      id-ct-zerotouchInformationJSON         [RFCXXXX]
>
>   id-ct-zerotouchInformationXML indicates that the "zerotouch-
>   information" is encoded using XML.  id-ct-zerotouchInformationJSON
>   indicates that the "zerotouch-information" is encoded using JSON.
>
> You define these values, but they are not used anywhere in the document.

Aye, you're right!  At least, they're not referenced by name, which
complicates searching for them...  (see my next response for more)



> It looks like you intended for this to be used in several places,
> for example:
>
> 3.1.  Zero Touch Information
>
>   When the zero touch information artifact is unsigned, as it might be
>   when communicated over trusted channels, the CMS structure's top-most
>   content type MUST be one of the OIDs described in Section 10.3, or
>   the OID id-data (1.2.840.113549.1.7.1), in which case the encoding
>   (JSON, XML, etc.)  SHOULD be communicated externally.  In either
>   case, the associated content is an octet string containing
>   "zerotouch-information" data in the expected encoding.
>
> Did you intend to use the above OIDs here?

Yes, exactly, and also in two other places in Section 3.1.  In
all three instances, we could either:

  OLD:
    ...one of the OIDs described in Section 10.3,

  NEW1:
    ...one of the OIDs described in Section 10.3 (i.e., 
    id-ct-zerotouchInformationXML or id-ct-zerotouchInformationJSON),

or

  NEW2:
    ...one of the OIDs described in Section 10.3 (i.e., 
    1.2.840.113549.1.9.16.1.TBD1 or 1.2.840.113549.1.9.16.1.TBD2),

Do you have a preference?



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 4.2.  DNS Server
>
>   To use a DNS server as a source of bootstrapping data, a device MAY
>   perform a multicast DNS [RFC6762] query searching for the service
>   "_zerotouch._tcp.local.".  Alternatively the device MAY perform DNS-
>   SD [RFC6763] via normal DNS operation, using the domain returned to
>   it from the DHCP server; for example, searching for the service
>   "_zerotouch._tcp.example.com".
>
> I agree with Adam that "zerotouch" much be a registered as service 
> name, see https://www.iana.org/assignments/service-names-port-numbers\ /service-names-port-numbers.xhtml.

Agreed, and I responded to Adam previously as follows:

  ===start===
  You are quite right.  Here is the Github commit to add an IANA registration
  for the "zerotouch" service:  https://github.com/netconf-wg/zero-touch/commit/6280763339a3e91b9efb21703b26a6bdbf05349b.

  Please let me know if you suggest any further changes.  
  ===stop===

And likewise, Alexey, please also let me know if you suggest any 
further changes.  




>   Artifact to Resource Record Mapping:
>
>      Zero Touch Information:  Mapped to a TXT record called "zt-info"
>        containing the base64-encoding of the binary artifact described
>         in Section 3.1.
>
>      Owner Certificate:  Mapped to a TXT record called "zt-cert"
>         containing the base64-encoding of the binary artifact described
>         in Section 3.2.
>
>      Ownership Voucher:  Mapped to a TXT record called "zt-voucher"
>         containing the base64-encoding of the binary artifact described
>         in Section 3.3.
>
> So just to double check, these would be zt-info._zerotouch._tcp.example.com,
> etc?

I'm not a DNS expert, but my understanding is that lookup would be on, e.g., _zerotouch._tcp.example.com and that the TXT records would be returned as follows:

_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_info=base64encodedvalue=="
_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_cert=base64encodedvalue=="
_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_voucher=base64encodedvalue=="

For instance ['\' added for readability]:

  # dig txt gab.com
  <snip/>
  ;; ANSWER SECTION:
  gab.com.		300	IN	TXT	"v=spf1 include:_spf.protonmail.ch mx ~all"
  gab.com.		300	IN	TXT	"ca3-56e3739f7f644cdaaa0e7edc903cf648"
  gab.com.		300	IN	TXT	"protonmail-verification=\
                                  96ca5019e36fc3a6dc5c4399efabe68792e55cc7"
  <snip/>

Do you feel that an example in the document is warranted?




> 8.1.  DHCPv4 Zero Touch Option
>
>      o bootstrap-server-list: A list of servers for the
>         client to attempt contacting, in order to obtain
>         further bootstrapping data, in the format shown
>         in [common-field-encoding].
>
> [common-field-encoding] in this and subsequent sections looks like a
> reference to Section 8.3. Please fix before publication, as this looks
> like an undefined reference.

Good grief, fixed (in both locations)!

  s/[common-field-encoding]/Section 8.3/



> 8.3.  Common Field Encoding
>
>   Both of the DHCPv4 and DHCPv6 options defined in this section encode
>   a list of bootstrap server URIs.  The "URI" structure is an option
>   that can contain multiple URIs (see [RFC7227], Section 5.7).
>
>     bootstrap-server-list:
>
> This is confusing, because I believe the following is a single entry
> in the list, not the whole list syntax:
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
>     |       uri-length              |          URI                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
>
>     o uri-length: 2 octets long, specifies the length of the URI data.
>
>     o URI: URI of zerotouch bootstrap server, using the HTTPS URI
>       scheme defined in Section 2.7.2 of RFC7230.  URI MUST be in
>       form "https://<ip-address-or-hostname>[:<port>]".
>
> So if I am correct above, please clarify this by changing
> "bootstrap-server-list:" to "bootstrap-server-list is a list of 1 or more
> items, each with the following syntax:" (Or something like this.)
>
> Also, "URI" deserve to be a Normative Reference, as it defines the
> generic syntax you are referring to.


I have ask my coauthor, Ian, to respond to this comment.



Thanks again!
Kent