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

Adam Roach <adam@nostrum.com> Thu, 10 January 2019 22:00 UTC

Return-Path: <adam@nostrum.com>
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 BD90013127E; Thu, 10 Jan 2019 14:00:25 -0800 (PST)
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 wpCFXEz_8ePU; Thu, 10 Jan 2019 14:00:24 -0800 (PST)
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 4D0A1131218; Thu, 10 Jan 2019 14:00:24 -0800 (PST)
Received: from Svantevit.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 x0AM0CUU013261 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 16:00:14 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547157616; bh=GZ6WbFvhYNjbnQJ6u+TWxv/SjAlUYpXp04ZZ0jRKbaY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YIW2sbys3LbIFz6yCvi9EoIY9Fj6HKe3kp90RjGkPnbkQ+URJrfvK2WanNVng/Gx0 56/b+rxYuervjPSFzfDgX0AigT85H9fs7oCAN9mVBmP7U3DLFvTXwynAWnncr1mLFl f+vVuzba8eZxYr9VByaYebFcSBgd/Z1Lp2PQjl5k=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at
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@ietf.org" <netconf@ietf.org>
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>
From: Adam Roach <adam@nostrum.com>
Message-ID: <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com>
Date: Thu, 10 Jan 2019 16:00:07 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9J_1gBo0lp63OeZz86Bzb0Y7T-Y>
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: Thu, 10 Jan 2019 22:00:26 -0000

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