[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF over TLS



David B Harrington wrote:
Hi Eliot,

This whole thing is sounding more TLS-specific and
less NETCONF-specific every day.

IMO, the Network Configuration WG is working on a network configuration
protocol.  The optional notifications do not change the focus of the protocol.
Transport and security problems are not the focus of this WG either.

I would rather the WG spend energy on finishing the Notifications draft,
or even discussing access control or data modeling on the NGO list.
Or even better, ignore this email thread altogether because you are
too busy implementing NETCONF to notice ;-)

Andy


-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] Sent: Tuesday, June 19, 2007 11:35 AM
To: David B Harrington
Cc: 'Phil Shafer'; 'Andy Bierman'; 'Netconf (E-mail)'
Subject: Re: NETCONF over TLS

Dave,
Many already know I favor a common secure transport layer
for multiple
NM protocols. I think the concept of BEEP is wonderful, since it
**standardizes** secure transport for NM, providing a more secure
environment across NM interfaces, and reducing security
configuration
work. But operators seem to refuse to use it, either because the
toolkits that have been available were not good enough, or the
deployment introduces more problems than it solves.
Until recently operators didn't have a choice to even deploy it, so I'd not read too much into what operators think right just yet.

I understand the sentiment, and maybe we shouldn't put much stock in
what operators have done so far. However, I think operators did have a
choice of multiple syslog implementations that implemented
syslog/BEEP, and weren't sold by that solution. I don't understand why
they will be sold by Netconf/BEEP.
Until BEEP is accepted by operators, I do not believe we should
disallow a Netconf/TLS transport just because there is a
Netconf/BEEP
transport. If BEEP is accepted by operators because it reduces the
work of deploying security for multiple NM protocols, the TLS
transport might just go away.
But it's not just TLS- it's TLS + User level authentication + framing. Guys, that's what BEEP is.

If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL
+ framing? Where is the value-add for using BEEP instead of using the
independent components? How does BEEP make it easier for an operator
to operate their network than if they simply used TLS + SASL + a
standardized framing approach?
Eliot




--
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/>




--
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/>