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

[Benjamin Kaduk <[e-mail]>]

On Fri, Jan 11, 2019 at 11:10:48PM +0000, Kent Watsen wrote:
> 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

Thanks, this seems to be a fine resolution of the issues.
While looking at the diff, I managed to confuse myself as to where it is
specified how the device serial number is encoded in the identity
certificate (so that we are confident that that encoding is usable as a
DNS label).  Am I correct in assuming that that's in 802.1AR?  (Also, the
URL in the -28 gave me a 404, and I ended up at
https://standards.ieee.org/standard/802_1AR-2018.html by searching.)

-Benjamin

> 
> 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 <[e-mail]>
> Date: Thursday, January 10, 2019 at 5:00 PM
> To: Kent Watsen <[e-mail]>, Benjamin Kaduk <[e-mail]>
> Cc: Dave Crocker <[e-mail]>, Alexey Melnikov <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, NETCONF Working Group <[e-mail]>
> 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
> 
>