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

Kent Watsen <kwatsen@juniper.net> Fri, 11 January 2019 23:11 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 2F8AA128B14; Fri, 11 Jan 2019 15:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.254
X-Spam-Level:
X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, 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 vV1CfltDxSF0; Fri, 11 Jan 2019 15:10:57 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.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 EDCC1128AFB; Fri, 11 Jan 2019 15:10:56 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0BN70w5030209; Fri, 11 Jan 2019 15:10:51 -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=GSqah2wMIhkCgejkLCHhmUnh+XAUPqqp+AJU9MqKars=; b=FRJYjokGm/4bfcjRysxje0Sncl0xTKbmmHrumie5uDXU2VZ2rVBf7ArX+TudCrQVTXwB isEVOUr4APSk7L9yS1ufXWcWr8efkztu8nwGe+/zqt+9JofwdPY4dSKAQV+3+jNTZE+q Am4PjDK9KoS2DGHUjX4NhAvKyUtFlubpZkNKG1jCi6TWy0J/V1GblfAAJRusBmBk+I9h AxYzTbIlZ9hwMEj3aVHt6JO6UZ8oeciOX4T89XS8QGdCDoyF5vWWeymuNSNm0zbMzAzF QkVTnNShXUNUxHvdPFqS93tGWmNLjQ8AQxNScSOwOj0VtXDtXBXimeHwsTnbKQQVGhlU Uw==
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2056.outbound.protection.outlook.com [104.47.45.56]) by mx0a-00273201.pphosted.com with ESMTP id 2pxw8cgmkw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Jan 2019 15:10:51 -0800
Received: from BYAPR05MB5416.namprd05.prod.outlook.com (20.177.184.221) by BYAPR05MB5080.namprd05.prod.outlook.com (20.177.231.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Fri, 11 Jan 2019 23:10:49 +0000
Received: from BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b]) by BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b%5]) with mapi id 15.20.1537.017; Fri, 11 Jan 2019 23:10:49 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Adam Roach <adam@nostrum.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: Dave Crocker <dcrocker@bbiw.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "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: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Thread-Index: AQHUi5qky69pAtgeuk6GIUpsNSYi7qVz1VIAgCLBFICAB70FgIADj4qAgAJJm4CAAxXrAIAAYVAA//+xH4CAAacWAIAAD4+AgAADiwD//8aMAIAActaAgAFSQoA=
Date: Fri, 11 Jan 2019 23:10:48 +0000
Message-ID: <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net>
References: <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net> <20181230003002.GC57547@kduck.kaduk.org> <5DCD6C74-7918-45AB-BEA7-2C1A020B4411@juniper.net> <20190106050255.GJ28515@kduck.kaduk.org> <35A436B3-5D57-4015-A51E-5F9A1E349D31@juniper.net> <DAC627AC-8453-41D2-B95C-BC25746E66C1@juniper.net> <cc5adc78-6751-fabf-03d2-e0c65f8a6c91@bbiw.net> <F844EDFB-3E15-47FB-A714-06363B996FC2@juniper.net> <42cddba1-9f59-f19f-176f-197f0c0c0c96@bbiw.net> <32cfe06c-8204-a63a-263d-cb5b30a7a2fc@nostrum.com> <20190110183444.GN28515@kduck.mit.edu> <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net> <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com>
In-Reply-To: <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.5.181209
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB5080; 6:eBhSaBf1++A+4yN7jgwHzaIxJ42HivBCtAhxwoOr0tDQmYWl49MYedbDT43RwUp1UhCOvEM1j3fm6LptGvVd0jhuCZjdVKutcr4qWaXmVwC41lg2zvm1cWOyIcP2vAX9pOHDfmjltM1zN+RlAkS8gJ1e2QTatf0yDAYCplAd6mmlYwJiZTpm8EopupTQN4At6eNpAv9bku28OqGD69ke/B1E805RFqpOFszD8KWtWRZ23FWKTe6UKhX+A3wsPsXAPE0QpeZKtfCBZ82ZsFHHzHwLp+Fom1rA9Ej+ulFPWqwOvnNyRL0hMS/9HMuCGyyOj7BqLwoteuhMdNFgc1XPFF5n4gVG9LhGevAeY7xD6EVMCYB4uE6L/qI7quvkClfDgHziFHpM41v3SaAWK96Xe731GASoKpaN7/wZUv4gr43KeCPO05R6Wn+ziexrDhVVpgU/rqpmYZf+L2kfmpK8IQ==; 5:bxDdPT9OcNYx0v7MJB4eNdYuK6ZmUoYLzVe40x4wgtZDkPZ5cQVb810xah0wnx3AmiI1kLGm1F6BsCFG1Rcvruk38psPletxp2SAlEcojWaQdeRcdSnZC8eG1sfHdYdcKgFdJdbv4ouUUMz6cchC1MLij+PMLT6gI+yubSzsECD+x0jScMX5PFSl/o1PFnDGqZHZCtn4T/17Fc9qdzOqJA==; 7:l/VemA9X3vsZXe3prNYBnD2HqdydpBKKijUWEC5CSIfDgevUUWNs/yWqLOrHuVYwypUwE5iRTnmPBH1JxvZXgNorROoYJTIdNXU+/T34o6+bnngScLF5P5Uu81s2XmCirdIi2SViCDCyDwDEzK6IMA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: ab08fa30-bc9b-42bd-7358-08d6781a065f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5080;
x-ms-traffictypediagnostic: BYAPR05MB5080:
x-microsoft-antispam-prvs: <BYAPR05MB5080EFA941BA9DE1BE649850A5850@BYAPR05MB5080.namprd05.prod.outlook.com>
x-forefront-prvs: 09144DB0F7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(39860400002)(346002)(396003)(13464003)(199004)(189003)(51444003)(14454004)(6506007)(102836004)(256004)(53546011)(99286004)(186003)(86362001)(25786009)(6436002)(6486002)(486006)(83716004)(71200400001)(36756003)(6512007)(2906002)(81156014)(66574012)(6306002)(81166006)(8676002)(7736002)(305945005)(11346002)(2616005)(71190400001)(66066001)(478600001)(26005)(446003)(476003)(53936002)(110136005)(68736007)(76176011)(54906003)(6246003)(4326008)(8936002)(58126008)(82746002)(33656002)(966005)(316002)(105586002)(14444005)(93886005)(229853002)(97736004)(5660300001)(2171002)(6116002)(3846002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5080; H:BYAPR05MB5416.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sOexugKPhUCgbGCUTBPk445nFCUb4diz+XBZSggKeT/01iKR3nb1mFOH0OBfvc2HbFcSqzidDyPpzUJEIv0DgtnJdf7SqjojaBwzM/EoFYuwa3CjwhaCGJa1Ep6iom6eKUf0qCzj7Db0Oe2xaTmjGin6iGfBxNPtfbFRiocCOu2b1E0XX9nlk2TBo188Jyfx34cqsP0ymXlcwI5CuDrm5HmPcXAaeKBntZM1oDWEdjxq/ZznKRe+dJHcAFURq56b6HV7mPfRLvz5LMV91NlcnszsknaqeJrBwcQ7+o9gw964n+QQgj9rU2PbOer6RPoFNPHgtJmXj0jol22LN8yEu4M1JH37iNIltgi+tWZVFcimAfxBMHgxelIRzNSBNkfPbs0BwIaRih/vErYDdqkGGs8MBfsd5QTUdjY5288EXv4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <BC28D8FA7BBA0D48BE95FD6A2CE71CE9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ab08fa30-bc9b-42bd-7358-08d6781a065f
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 23:10:48.9424 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5080
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-11_12:, , 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-1810050000 definitions=main-1901110182
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sPR53O1RqgCtxqfJZiLa7M9RY38>
Subject: Re: [Netconf] Benjamin Kaduk'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: Fri, 11 Jan 2019 23:11:00 -0000

Hi Adam, Benjamin, and Dave,

  I just posted -28 to address this last COMMENT.
  Please review to see how it can be improved.

  The draft no longer says it uses DNS-SD and it
  now registers "_sztp" in DNS Underscore Global
  Scoped Entry Registry.
  
  Here's a direct link to updated/new sections:
   - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-4.2
   - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-10.7


Adam,

  I added text about this draft not using DNS-SD.

  Also, after reviewing RFC6763, copied over the 
  recommendation that mDNS SRV responses also 
  include address (A and AAAA) records.  This was
  the only thing I can find of merit after searching
  for both the strings "multicast" and "mdns".  Was
  there something else you had in mind?


Thanks,
Kent


-----Original Message-----
From: Adam Roach <adam@nostrum.com>;
Date: Thursday, January 10, 2019 at 5:00 PM
To: Kent Watsen <kwatsen@juniper.net>;, Benjamin Kaduk <kaduk@mit.edu>;
Cc: Dave Crocker <dcrocker@bbiw.net>;, Alexey Melnikov <aamelnikov@fastmail.fm>;, The IESG <iesg@ietf.org>;, "draft-ietf-netconf-zerotouch@ietf.org"; <draft-ietf-netconf-zerotouch@ietf.org>;, "netconf-chairs@ietf.org"; <netconf-chairs@ietf.org>;, NETCONF Working Group <netconf@ietf.org>;
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

On 1/10/19 2:09 PM, Kent Watsen wrote:
>>> I don't think this is right. Draft-ietf-netconf-zerotouch is explicitly
>>> using DNS-SD procedures [1]. In turn, DNS-SD absolutely mandates the
>>> presence of both SRV and TXT records with the same name [2]. So the
>>> names need to match.
>> Whoops, that's totally an error on my part.  If we're explicitly doing
>> DNS-SD, then there's "nothing to see here".
>>
>> Sorry for missing that.
> No, wait, I think that the draft's stating that it uses DNS-SD procedures
> may be in error.  It might be more correct to say that it uses DNS in the
> following two separate/distinct ways (in order of device-processing):
>
>     1) A lookup for device-specific data (for the TXT RRs)
>
>        Currently is this:<serial-number>._sztp._tcp.example.com
>        But maybe should be: <serial-number>._sztp.example.com ???
>
>        Returns TXT records (no SRV records) supplying bootstrapping
>        data.


Aha! Okay, I had missed this in my read of the zeroconf document. I 
think I just saw "DNS-SD" and made certain assumptions. If this is the 
procedure you've specced out, then you can't use a TXT record with the 
_tcp global underscored name (since its use has to be consistent with 
the procedures spelled out in RFC 6763). The use of 
<serial-number>._zrtp.example.com would be fine, and would call for a 
registration in the attrleaf registry.


>        Only if this lookup fails (not in addition to), then the
>        device moves to (2), in conflict with RFC 6763 §6.3 says:
>
>          "DNS-SD uses DNS TXT records to store arbitrary key/value pairs
>           conveying *additional* information about the named service."
>          (emphasis mine)
>
>
>     2) A traditional SRV lookup (per RFC 2782, not DNS-SD, right?)
>
>        Example: _szpt._tcp.example.com
>
>        Returns SRV records (no TXT or PTR records) supplying
>        traditional service info (address, port, priority, weight).


Kind of? The issue here is that 2782 uses normal DNS lookup procedures, 
while zerotouch uses mDNS lookup procedures (if I've read things 
correctly). Doing mDNS with SRV records using _tcp but *not* using 
DNS-SD ends up stepping on DNS-SD's toes, at least a little bit. I 
suppose as long as "szpt" is registered in the service table (which is 
required for 2782 use), there's no practical risk of collisions.


>        FWIW, technically, SZTP defines an application-level protocol
>        on top of RESTCONF, which is on top of HTTPS, but I don't
>        think anyone is suggesting this:
>
>            _sztp._restconf._http._tls._tcp.example.com   ;)


I hate to admit that there's (kind of) precedent there, but it's *bad* 
precedent resulting from a misreading of 2782, and not something I'd 
encourage. :)

<snip>


> Note that the WG didn't know about draft-ietf-dnsop-attrleaf until just
> now in the IESG review.  We were shoe-horning in DNS-SD as it the closest
> fit.  But now that draft-ietf-dnsop-attrleaf is brought to our attention,
> perhaps it makes more sense to define a top-level "_sztp" attribute for
> the device-specific bootstrapping data?


FWIW, before attrleaf, the accepted approach was to land-grab a label 
and naïvely hope that no one ever tried to grab the same label twice. In 
any case, even with attrleaf (and based on your clarifications above), I 
think the <serial-number>._sztp.example.com formulation for TXT is 
correct. With attrleaf, it's even more clearly so.

All of that said, you'll need to put additional language in here about 
using SRV with mDNS, but *NOT* using DNS-SD procedures. I'd advise 
copying and modifying appropriate passages from DNS-SD as the basis for 
such language. Also, please be certain to be very clear about the 
relationship between this mechanism and DNS-SD.

/a