[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on NetConf Requirements
Juergen Schoenwaelder wrote:
A channel exists on top of a connection and so why does the concept of
a channel make it easier to establish connections?
Because it abstracts away who connects. If a device is behind a
firewall, it can connect to the manager. If the manager is behind a
firewall, it can connect to the device. Similarly so for NATs. Once
the connection is made, either side can initiate an appropriate profile.
So, just because I've connected to you doesn't mean that I'm the manager.
I agree that authentication has to be tied into radius or something
similar. So how does BEEP help here?
It uses SASL which can be tied in on the back end to just about anything.
My understanding so far was that operators script the CLI and do not
use HTTP or other mechanisms (unless the CLI is so hard to script with
ugly menus and such things that they do not have a choice).
And that's not going away. If they want to keep doing it they can, but
the things SASL provides are just those sorts of things that the
operators need protection against. One of the most fragile parts of
these home made scripts is the authentication component. Why? For
whatever reason its behavior varies in CLIs from time to time. Part of
it has to do with just getting to and beyond the password, where someone
has changed the banner or motd to something that catches an expect script.
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/>