Re: NETCONF over TLS

[Simon Leinen <simon.leinen@switch.ch>]

David B Harrington writes:
> BCP72 identifies TLS as the transport security mechanism of choice
> when traffic is over TCP. SSH is recommended for remote login
> security, for providing channel-level security directly in the
> application.

> Netconf is designed to do "network configuration" as a
> replacement/supplement to the CLI running over a remote login
> session.  But when netconf starts to move into notifications and
> into monitoring, then I think the argument for remote login gets
> weaker.

One could say that, conversely, the argument for other transport
features (such as multiple channels) gets stronger.  But so far the WG
seems to tend to reduce the transport requirements, viz. the evolution
of the notification mechanism, which now works over a single channel.

> If netconf is meant for "network configuration", i.e., configuring
> all types of nodes in the network, then there are some questions to
> ask: 1) key distribution is important; do more network nodes already
> support TLS (and thus have certificates already distributed) or
> already support SSH (and already have SSH-related credentials
> distributed?

For the environments I'm familiar with ("classical" ISPs):

* Fully manageable nodes support both SSH and TLS; SSH for access to
  the CLI, and TLS for access to the integrated HTTP server.

* Operators often enable SSH but leave TLS disabled, because HTTP is
  not usually used for management in these environments.

> 2) Will netconf provide application-level security beyond what the
> secure transport provides, such as data access controls?

I absolutely expect that at least some NETCONF implementations will
provide facilities to restrict access to certain parts of the
configuration based on user identities.  Some vendors do this today
for CLI-based configuration.

> If so, will this be easier using TLS or SSH? What attributes need to
> be passed up from the transport security to the application to
> provide these extra services?

The systems that I'm familiar with makes these decision based on user
identity (username).  This is readily available with SSH, but usually
not with TLS.

> 3) Which is easier to integrate with AAA protocols, such as RADIUS
> and Diameter?

SSH has been integrated with AAA protocols (RADIUS and TACACS+ in our
case).  I don't know whether this has been done with TLS.

> 4) and most important, what would the operators use if both SSH and
> TLS were available?

The one that's more likely to be widely implemented and that fits
better into their existing AAA infrastructure, I would guess.
-- 
Simon.

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>