We are testing with confd using both SSH or TLS.
The scenario is that we create two connections (either SSH or TLS). Both has same protocol.
Then we get the session ids for each eg. ID 1 and 2 for each one.
Then in our client we call:
so we kill NETCONF session for the other connection.
We can see the is sent for the session and
ww get a in rpc reply.
Now here is the difference:
- For SSH, transport is also closed not only NETCONF session. So we have no connection more.
- For TLS, transport is not closed only the NETCONF session. We still have a connection.
I can see from our client, it is sent a “alert write:warning: close notify” but nothing that indicates
server responding to this. According to protocol there should be a close handshake to avoid
“man in the middle”-attack.
This is the RFC ,rfc6241, for kill-session.
Description: Force the termination of a NETCONF session. When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued. Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock.
- How do you interpret the NETCONF spec. Should physical connection be closed too?
- How is it implemented for both protocols in ConfD? What can we expect with physical connection when doing a kill-session?