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

Re: NETCONF over TLS

Phil Shafer wrote:

Andy Bierman writes:

So, with this new 'special' <request-login> RPC (that creates
a layer violation in itself) the agent needs to send 'operation-failed'
errors for any other RPC received before this one?  A special mode is needed
in the RPC handler, based on, and coupled to, the transport protocol
used to establish the session -- just to support this special RPC method.


The rules to handle this were pretty simple:

- The <request-login> RPC could only be performed if the session wasn't
  authenicated.
- No other RPCs could be performed if the session wasn't authenicated
- The transport protocol can authenticate the session (internally)

So over ssh, the session is authenticated by the transport protocol,
which calls a function to pass this information up to the netconf layer.

Over ssl/tls, the session starts with no authentication, leaving the
<request-login> RPC as the only valid RPC.  Anything else is an error.



IMO, this should be handled with a different top-level element
than <rpc>, outside the scope of the NETCONF protocol.
That way, no special RPC code is needed at all.
Only sessions that have been properly authenticated, and <hello>
messages are okay, should be allowed to use <rpc> methods.


Thanks,
 Phil



Andy

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