1 / 13

draft-kwatsen-netconf-zerotouch-00

draft-kwatsen-netconf-zerotouch-00. Zero Touch Provisioning for NETCONF Call Home. Introduction.

myra
Download Presentation

draft-kwatsen-netconf-zerotouch-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-kwatsen-netconf-zerotouch-00 Zero Touch Provisioning for NETCONF Call Home

  2. Introduction Zero Touch is a strategy for how to establish a secure network management relationship between a newly delivered network element, configured with just its factory default settings, and the new owner's NMS.

  3. Goals Security • MUSTimplementvs MUST use(RFC 3365) Flexibility • Works on SP networks, even if behind a firewall Ease of Use • Play-n-play for Installer (“zero” means zero!) Device Cost • Mild (COGS + development effort)

  4. Proposal illustrated in following slides

  5. Device State Precondition +--------------------------------+ | <device> | | | | +----------------------+ | | | <crypto processor> | | | | | | | | device private key | | | | device certificate | | | +----------------------+ | | | | FQDN of vendor's DNS server | +--------------------------------+ Serial Number Signed by certificate with chain of trust to Vendor’s well-known CA

  6. Vendor's DNS Server State +-------------------------------------------------+ | <vendor's DNS server> | | | | <sha1-of-device-public-key>.<vendor-zone> | | - FQDN of NMS to connect to | | - flag indicating if SSH or TLS | | - username NMS will login using | | - NMS's auth credentials | | | +-------------------------------------------------+ • State initialized through a vendor-hosted interface

  7. ZeroTouch Sequence Diagram DEVICE LOCAL DHCP LOCAL DNS VENDOR'S DNS NMS | SERVER SERVER SERVER (DNSSEC) | | | | | | |------------>| | | | | Lease IP | | | | | | | | | |------------------------------->| | | | Lookup vendor's DNS server | | | | | | | | |---------------------------------------------->| | | Lookup <sha1-of-device-pub-key>.<vendor-zone> | | | | | | | |------------------------------->| | | | Lookup NMS IP address | | | | | | | | |------------------------------------------------------------->| | Reverse SSH or Reverse TLS | | | | | | | |

  8. NMS State Precondition +----------------------------------------+ | <NMS> | | | | vendor's trusted CA certificate | | serial numbers for expected devices | | username to log into devices with | | auth credentials to log into devices | | | +----------------------------------------+ • NMS needs CA cert and serial-numbers from Vendor

  9. Supporting Private Networks • Potential alternatives to source information: • Impersonate vendor’s DNS server • DHCP (susceptible to a MITM attack?) • USB flash drive • Near-field wireless • Or just to avoid doing a lookup in the vendor’s DNS server?

  10. Security Considerations • Long-lived certificates • Vendor may reveal NMS locations • Serial Number in certificate

  11. IANA Considerations • None

  12. Open Issues • DNSSEC doesn't currently allow client certificates • Should DNS record provide SSH-specific information? • Standardize REST API used to set DNS record info? Not in -00 draft: • Use something besides DNS? (e.g. HTTPS)

  13. Questions / Concerns ?

More Related