Subject: [Netconf] draft-kwatsen-netconf-zerotouch

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Oct 2013 22:34:56 +0000

All,

This draft slipped the submission deadline, so I posted it to another site.

http://softnami.com/draft-kwatsen-netconf-zerotouch-00.txt
http://softnami.com/draft-kwatsen-netconf-zerotouch-00.html

Hopefully we can still discuss it on the list before the meeting in Vancouver.

Thanks,
Kent

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 31 Oct 2013 01:29:50 -0400

> Hopefully we can still discuss it on the list before the meeting in

Ken et al, why would the device need the FQDN of the vendor's DNS 
server?  Couldn't it use the domain name with an NS query to get this? 
I'm trying to think of something that may be more scalable over time 
(i.e., if an older device is deployed that may have an old FQDN).

What type of DNS queries will be used to get the NMS name and 
credentials?  It would be helpful to see a query flow diagram in this draft.

In the security considerations, you mention the potential threat in a 
malicious party learning the NMS FQDN, but I think the NMS authn 
parameters are more sensitive.  Additionally, there may be hesitance of 
customers to store authn parameters within a vendor database.  One 
potential workaround of this might be an alternate DNS address that the 
new device can query in the customer's network that would provide these 
bits of info.  This would maintain the ability to support 
customer-unconfigurable DHCP servers while still allowing things like 
the NMS parameters to be maintained within the customer's network.

Nit: your link to rfc5539bis points to 6187 instead.

Joe

>
> Thanks,
> Kent
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Oct 2013 12:41:24 +0000

Hi Joe,

>why would the device need the FQDN of the vendor's DNS

Because we need to support devices connected to ISP networks (think
McDonalds, Radio Shack, etc.), we cannot assume the presence of any
locally-administered server (DHCP, DNS, LDAP, etc.) that a device could
extract deployment-specific information from.  From the device's
perspective, its local DHCP and DNS servers are administered by the ISP,
who is disinclined to allow its customers to insert customer-specific
information into them.

>credentials?  It would be helpful to see a query flow diagram in this

I guess it would be the 'A' record for the
<sha1-of-device-pub-key>.<vendor-zone> entry.  As pointed out in the Open
Issues section, already we need to extend DNS to accommodate some data, so
including this data in that analysis as well makes sense.  Being a -00
with no implementation as of yet, we're really just fishing to see if the
IETF has interest.  If so, then we'd be sure to lock down all the unknowns
at that time.

>the NMS parameters to be maintained within the customer's network.

Regarding auth parameters, we'd only support storing public keys or hashed
passwords.  As such, the concern for who has access to them is essentially
eliminated.  With large enough keys lengths, even a brute force attack
would be acceptably unlikely.

I like your idea to have the device's lookup in the vendor's DNS server
pull down the FQDN of a customer-specific DNS server that it could then
query for the customer-specific parameters.  For that matter, it wouldn't
have to be a DNS server anymore, it could even be an HTTP server.
However, in order to ensure security, a trust-anchor for *that* server
would have to provided from the lookup in the vendor's DNS server.  Still,
it's less than what the current draft proposes - definitely worth
analyzing!

>Nit: your link to rfc5539bis points to 6187 instead.

Fixed in my local copy - thanks!

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Oct 2013 13:58:40 +0100

> who is disinclined to allow its customers to insert customer-specific

http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configuration-05

Probably not the best document but still a pity that it kind of died.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Oct 2013 16:36:44 +0000

>Probably not the best document but still a pity that it kind of died.

The concern was for the perceived utility of the document.  I didn't fully
understand the issue, especially since it was an Informational document.

Regardless, it could be said that Zero Touch is a specific implementation
for what's discussed in that draft.   If there is interest in Zero Touch,
I will add a section referencing that draft and how Zero Touch
conforms/deviates from it.

Maybe Zero Touch will garner more support, as its focus is specific to
NETCONF, leveraging the recent reverse-TLS/SSH drafts we're working on
now.  Then again, some might say they want a more holistic solution that
works using SNMP too.  We'll see...

Thanks,
Kent

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 31 Oct 2013 17:45:49 +0100

My personal recommendation would be:

- we failed some years ago to go for a generic/holistic solution.

- let us now focus on a point solution for NETCONF

so we do no re-waste a lot of cycles.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Oct 2013 20:20:22 +0100

Except that the I-D was never a solution document. It tried to provide
an overview what is out there - anyway, I am over it.

/js